← Prev in month ← Prev in thread

DITA XML Schema backwards compatibility and conformance

From
Eric Sirois <>
Date
2008-03-31T20:07:44+00:00
ID
Thread
DITA XML Schema backwards compatibility and conformance
Hello,

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,

Eric

In the examples below we have the following
samples in the Language specification.   

Example 1

<prolog>

<critdates>

<created date="2001-06-12"></created>

<revised golive="2001-08-20"></revised>

</critdates>

</prolog>

Example 2

<prolog>

<critdates>

<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"/>

</critdates>

</prolog>

Eric A. Sirois

Staff Software Developer 

DB2 Universal Database - Information Development

DITA Migration and Tools Development

IBM Canada Ltd. - Toronto Software Lab

Email: 

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.
← Prev in month ← Prev in thread