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 XML Schema backwards compatibility and conformance

The DITA 1.1 spec says that “[w]hile the DTDs and schemas should define the same DITA elements, the DTDs are normative if there is ever any discrepancy”.  To me this means that when the DITA specification itself is silent or ambiguous, that the XSDs need to treat as valid any document that would be considered valid using a DTD. I can’t see updating the DITA 1.2 specification in ways that could make existing DITA 1.0 or 1.1 documents invalid.


While that is what I think the current situation is, I’ll be interested to see if others agree.


Are there any other cases with DITA 1.1 where the Schemas are stricter than the DTDs?  Anything having to do with URIs?


In many respects it is too bad that the DTDs are normative since DTDs aren’t nearly as capable as Schemas. I’ve been wondering for sometime if we shouldn’t flip things around in DITA 2.0 and make the Schemas normative. Of course I am not sure when we’ll be seeing DITA 2.0, so this may be speculation for the distant future.




From: Eric Sirois [mailto:esirois@ca.ibm.com]
Sent: Monday, March 31, 2008 4:07 PM
To: dita@lists.oasis-open.org
Subject: [dita] DITA XML Schema backwards compatibility and conformance



While working on a prototype using the XML Schemas (XSD) and converting DITA-OT user guide from DTD validated documents to XSD validated documents, in a few cases the new documents we not valid against the schemas.  

Was there a bug in the schemas?  The answer to this questions depends on how you interpret the contents of the language specification.  It's a topic I think we need to resolve for DITA 1.2.  If the TC decides the schemas are wrong, then I can retrofit the fix into DITA 1.1.

The current specification does not mention or address the conformance level of the DTDs and XSDs.  I want to state that element and structure wise the DTDs and XSDs are equivalent.  The current "grey" are is the content, for now, in a couple of places.  The area in which we don't specifically have a conformance statement (must/should) on how DITA should deal with Dates and time, specifically ISO 8601. We do to a URL that summarizes ISO 8601.

XSDs have specific support for ISO 8601 as native datatypes. In the examples below, if @date, @golive and @expiry were implemented in the XSD as type xs:date.  The content in example 2 would be valid in the DTDs, but not valid in the XSDs....The main question is - Should it fail?

With XSDs, the parser can help enforce the format using patterns or native datatype.  With DTDs anything is allowed as content. Is that okay?  The other case in point is dealing with the @year attribute in the copyright   In the current language specification it mentions that the format is YYYY.  In the schema I use gYear as the datatype.  It only allows one single year value as the content.  So if a parser we presented with <copyright  year="1999, 2007"/>. The schema validation will fail.   This @year value is of type xs:gYear in the current DITA 1.1 schemas.    

When I initially implemented the schema I interpreted the specification as one year per element.  I could be wrong.  Reading the current wording of the specifications, I not able to determine which one is wrong, XSD, the use case, or both.

Does it make sense to have a conformance statement for ISO 8601?  Should XSDs help enforce the conformance statement in  this case, knowing that once DTDs validated documents would possibly be invalidated once the are validated against XDSs?  

Kind regards,

In the examples below we have the following samples in the Language specification.  
Example 1
<created date="2001-06-12"></created>
<revised golive="2001-08-20"></revised>

Example 2
<created date="1/1/1999" golive="2/15/1999" expiry="9/9/9999"/>
<revised modified="3/3/2003" golive="2/3/2002" expiry="9/9/9999"/>

Eric A. Sirois
Staff Software Developer
DB2 Universal Database - Information Development
DITA Migration and Tools Development
IBM Canada Ltd. - Toronto Software Lab
Phone:(905) 413-2841
Blue Pages (Internal)

"Transparency and accessibility requirements dictate that public information and government
transactions avoid depending on technologies that imply or impose a specific product or
platform on businesses or citizens" - EU on XML-based office document formats.

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