Re: [dita] Proposal for DITA namespaces

[Eliot Kimber <ekimber@innodata-isogen.com>]

Erik Hennum wrote:

> Because of these design questions and the uncertain standards and tool
> environment, the TC may want to defer resolution of the namespace issues
> until the next version of DITA.  This approach would give the TC time to
> come up with an optimal design, to push for enhancements to evolving
> standards (especially for XSLT 2 to support XML Schema 1.1), and to push
> for conformance by XSLT processors and other tools.

I agree that these are important concerns, but I will re-iterate that my 
*primary* reason for wanting one or more DITA-specific namespaces is so 
that document instances can be unambiguously identified as DITA-based 
documents.

I still feel very strongly that this is a compelling reason to define 
namespaces.

I also suspect that schema-based inheritance is a red herring and that 
we should ignore it. This is because DITA specialization is applied at 
the application level (the level of post-parsing processing, where 
semantic constraints are applied and checked) while schema-level 
specialization is applied at the parsing (syntactic constraints) level.

One problem is that the historical DTD-based processing used in DITA 
(all other historically SGML-based systems) conflates the semantic and 
the syntactic because it was easy to do so and because we didn't have 
good tools and terminology for keeping the two separate (remember that 
practical SGML usage predates mainstream object-oriented program by 
about 10 years).

Today we have the concepts, vocabulary, and tools to clearly distinguish 
the domains of syntactic constraint and semantic constraint.

While it is convenient, especially for system implementors, to use 
syntatic constraints to validate the correctness of DITA documents, this 
validation is, I think, more appropriately done post parsing. There's no 
technical reason it couldn't be done there and doing it here would avoid 
a whole host of constraints imposed by the architecture and 
implementation choices of standards and technologies over which we can 
have little control.

Or said simply, it has always been the case that all SGML and XML 
applications needed a special-purpose validation application in order to 
be completely validated. It happens that in the case of DITA that the 
amount of validation that can only be done in this application is about 
80% of the rules, rather than the 20% that is typical for most 
traditional markup applications.

> One consequence of this deferral would be that the DTD version would likely
> remain normative in the first version of DITA.  While this gives DITA the
> appearance of lagging behind standards, the TC could clarify that an XML
> Schema implementation is available, that a normative XML Schema
> implementation should make full use of the advanced type inheritance
> features, and that an XML Schema implementation is likely to become
> normative once support for type inheritance stabilizes in the Schema and
> XSLT standards and gets widespread support in tools.

I would have a hard time supporting a standardized form of DITA for 
which a namespaced schema was not either the or one of the normative 
declarative forms.

Cheers,

Eliot
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122

eliot@innodata-isogen.com
www.innodata-isogen.com