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: 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]