[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Proposal for DITA namespaces
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]