[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA 1.1 DTD error
I'd think that, if there were anyone using this attribute, they would have noticed the bug and reported it. In particular, I doubt the toolkit handles longdescre properly, so there isn't really any backward compatibility issues since such an attribute never worked. Also, as it stands, the XSDs now validate a different doctype than the DTDs, as the XSD has: <xs:attribute name="longdescref" type="xs:string"/> And, of course, the documatnion in the spec has longdescref, and in my view, the spec is the normative definition of DITA, not a particular file in the distribution. I don't feel comfortable continuing in the vein that object's longdescref's attribute is spelled longdescre. 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 > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Sunday, 2007 January 07 21:32 > To: Grosso, Paul > Cc: dita@lists.oasis-open.org > Subject: Re: [dita] DITA 1.1 DTD error > > Hi Paul, > > It has been that way since DITA 1.0. It looks like it was > correct back in > the pre-OASIS version, which means it may have been a > casualty of the DTD > spacing/comment cleanup at the time the standard was approved. > > Because it was in DITA 1.0, this gets into the realm of the backwards > compatibility vs bug area. It is clearly a bug. But, it's > just as clearly > backwards incompatible to change the name of an attribute. > Changing it will > break existing 1.0 documents, if by any chance somebody is using the > attribute today. > > 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/06/2007 11:32:10 AM: > > > We just noticed that the longdescref attribute on the > > object element in commonElements.mod is missing the > > trailing "f" in the version 1.1 dated 30 Nov 2006 available at > > > http://www.oasis-open.org/apps/org/workgroup/dita/download.php > /21381/dit > > a1.1.zip > > > > <!-- LONG NAME: Object (Streaming/Executable > > Data) --> > > <!ELEMENT object ((%desc;)?, (%param;)*, > > (%foreign.unknown.incl;)*) > > > > <!ATTLIST object > > declare (declare) #IMPLIED > > classid CDATA #IMPLIED > > codebase CDATA #IMPLIED > > data CDATA #IMPLIED > > type CDATA #IMPLIED > > codetype CDATA #IMPLIED > > archive CDATA #IMPLIED > > standby CDATA #IMPLIED > > height NMTOKEN #IMPLIED > > width NMTOKEN #IMPLIED > > usemap CDATA #IMPLIED > > name CDATA #IMPLIED > > tabindex NMTOKEN #IMPLIED > > longdescre CDATA #IMPLIED > > %univ-atts; > > outputclass > > CDATA > #IMPLIED > > > > > Is there a later version that I missed? > > > > If not, then this looks like a bug in the DTDs. > > > > paul >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]