OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [dita] DITA 1.1 DTD error


After thinking about this more and consulting a few co-workers, I'd really
prefer Paul's third approach now:
> 3.  allow both longdescref and longdescre attributes on object
>     for 1.1---deprecating longdescre and removing it in 2.0--so
>     that any legacy files using the misspelling won't cause
>     validation errors when used with the DTDs, but indicate
>     that implementations do not need to do anything with the
>     longdescre attribute (since I'm sure no implementations
>     do anything with it now).

I do think it's relatively unlikely that people are using this attribute
today. However, I think it's possible that somebody would set it without
noticing that a letter was missing. They wouldn't know it was broken unless
they looked at the docs at the same time, or carefully checked the output
to find it was not working.

Rather than have people blame DITA (or their current tool) when their docs
no longer validate, I'd rather deprecate it for a while first. We can have
the toolkit warn people and explain how to fix the problem; the language
reference can indicate that tools may issue an error for the bad version.

Anybody else care about this, aside from myself and Paul?

Thanks-

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787

Robert D Anderson/Rochester/IBM@IBMUS wrote on 01/08/2007 03:15:22 PM:

> I would favor option 2 or 3. Option two probably makes the most sense,
> given that I do not anticipate any tools specifically supporting
> "longdescre" (even if they do support setting it).
>
> Given that there will be a DTD update for this - I would also like to
> include one non-functional change in the DTDs. There is a parameter
entity
> in the DTDs called filter-atts. It includes all of the attributes that
the
> spec says are to be used for filtering, flagging, etc. It also includes
the
> new base attribute, which the spec says is not to be used for filtering.
I
> would like to move this out of the entity and into the locations which
use
> this entity. As I said, not a functional change, but it may prevent
> misconceptions that come about through browsing the DTD -- which I know
> many of you do on weekends.
>
> Thanks-
>
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> (507) 253-8787, T/L 553-8787
>
> "Grosso, Paul" <pgrosso@ptc.com> wrote on 01/08/2007 09:08:11 AM:
>
> > I suggest that we fix the DTD now in 1.1.  Additionally, we
> > can do one of three things:
> >
> > 1.  nothing--it's a bug fix;
> >
> > 2.  add a comment in the DTD and a note in the spec pointing
> >     out that earlier distributions had a misspelling in the DTD;
> >
> > 3.  allow both longdescref and longdescre attributes on object
> >     for 1.1---deprecating longdescre and removing it in 2.0--so
> >     that any legacy files using the misspelling won't cause
> >     validation errors when used with the DTDs, but indicate
> >     that implementations do not need to do anything with the
> >     longdescre attribute (since I'm sure no implementations
> >     do anything with it now).
> >
> > paul
> >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]