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
www.innodata-isogen.com
