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.
-Jeff
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
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: esirois@ca.ibm.com
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.