Re: [dita] Proposal for DITA namespaces

[Erik Hennum <ehennum@us.ibm.com>]

Honored Members of the DITA Technical Committee,

Eric Sirois and I have been kicking around the namespaces issue offline and would like to bring forward some considerations.


** A typical rationale for namespaces is to support combining XML vocabularies by preventing collisions between the element names in each vocabulary. DITA, however, has the additional concern of preventing collisions between specialization packages within the DITA vocabulary. (Specializations are, in effect, vocabularies in their own right.) At a minimum, each supplier of specialization packages should have a distinct namespace.


** A second use of namespaces is to allow processable statements about XML vocabularies. For instance, a RDDL file could provide a human-readable summary of a specialization package as well as a machine-processable listing of the document type modules, transform modules, and documentation files for the specialization package. Similarly, by establishing a convention that identifies elements through a combination of the namespace for the package with the element name, it would be possible to make RDF statements about elements. To provide a systematic approach for identifying both specialization package resources and for making statements about elements, each specialization package should have a distinct namespace.


** The relationship between namespaces and DITA type inheritance needs to be thought through carefully, both in light of good design and support by XML Schema and XSLT implementations. In particular, with work starting on XML Schema 1.1 and no clear statement from XSLT 2.0 on whether XML Schema 1.1 will be supported, the design constraints aren't clear. We don't want to institute a design for namespaces to find that no tool supports it or that the next generation of tools will permit a better design.


** In particular, the relationship between the specialization package namespace and the package identifier in the class attribute needs to be thought through. Ideally, the class attribute would express the element ancestry as a list of qualified element names (where the qualifier is the namespace prefix), so the qualified element name would be the same in the class attribute as in other contexts. Unfortunately, to prevent collisions, the document type must be able to assign the prefix to the namespace URI. The namespace URI itself is stable, but the namespace URI is too verbose to serve in the class attribute.


** The impact of namespaces on authoring needs to be thought through. While the ability to prevent naming collisions is crucial, many DITA document types will assemble specializations that don't have naming collisions. In such cases, requiring namespace prefixes on elements merely imposes clutter on the author. We might be able to come up with a design so the document type controls whether a specialization package has a namespace prefix or, instead, becomes the default namespace for its elements. Inherited attributes may pose some challenges for this goal.


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.

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.


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com



Paul Grosso <pgrosso@arbortext.com> wrote on 07/19/2004 01:33:49 PM:

> Though it's true that RFC 3121 defines a URN namespace for OASIS,
> Norm (the author of said RFC) has changed his mind on this.  See:
> http://norman.walsh.name/2004/03/03/266NorthPleasant which Norm
> wrote after the W3C TAG's Web Architecture document at
> http://www.w3.org/TR/webarch/
> came out in favor of resolvable URIs for namespace names.  Norm
> now suggests using http: URIs for namespace names.
>
> DocBook NG uses http://docbook.org/docbook-ng .
>
> DocBook V5 will probably use something analogous.
>
> paul
>
> At 16:19 2004-07-16 -0400, Eric Sirois wrote:
>
> >Here is quick note to formally introduce and start some discussions
> >regarding namespaces for DITA XML Schemas.
> >
> >As per the RFC 3121(A URN Namespace for OASIS) [1] from IETF below you will
> >find some of the namespace that
> >could be applied to DITA XML Schemas.
> >
> >Here is a snippet the RCF that is of interest to the TC:
> >The RCF general structure for Technical Committee is the following:
> >Technical Committee Work Products
> >
> >         The "tc" hierarchy is for work products of OASIS Technical
> >         Committees.  The general structure of the NSS in the tc
> >         hierarchy has the form:
> >
> >            urn:oasis:names:tc:{tc-id}:{type}{:subtype}?:{document-id}
> >
> >         where "tc-id" is a unique identifier for the Technical
> >         Committee, and the remaining fields are assigned as per the
> >         specification hierarchy.
> >
> >Namespace suggestions:
> >Here are two namespaces that Eliot has been using for his modified version
> >the XML Schemas for his application xiruss-t
> >map - urn:oasis:names:tc:dita:map
> >ditabase - urn:oasis:names:tc:dita:base
> >I believe in this case that the four base XML Schema all have the same
> >namespaces.
> >
> >Below is a list of namespaces that could apply to topic, task, concept, and
> >reference.
> >topic - urn:oasis:names:tc:dita:topic
> >task - urn:oasis:names:tc:dita:task
> >concept  - urn:oasis:names:tc:dita:concept
> >reference - urn:oasis:names:tc:dita:reference
> >
> >Domains could have their own namespaces (as part of Method 2 - see below).
> >highlight-domain - urn:oasis:names:tc:dita:highlight-domain
> >programming-domain urn:oasis:names:tc:dita:programming-domain
> >ui-domain - urn:oasis:names:tc:dita:ui-domain
> >utilities-domain - urn:oasis:names:tc:dita:utilities-domain
> >software-domain - urn:oasis:names:tc:dita:software-domain
> >
> >
> >There are a couple methods in which a namespaces can be bound to the XML
> >Schemas.
> >
> >Method - 1
> >  -The namespace for each specialization is bound in the schema shell
> >files.
> >  -The namespace would then be assumed (chameleon effect) by all included
> >schemas in the primary XML Schema and would not
> >affect specialization. For example, wiztask which includes task, topic and
> >the domains would all have the same namespace.
> >With this method we can make full use of XML Schema inheritance to create
> >new specialization.  Inheritance helps developers validate
> >new DITA specialization when validating the XML Schema rather that manually
> >checking whether or not a new specialization follows the
> >DITA specialization rules.
> >
> >Method - 2
> >  -The namespace for each specialization is bound in the in the schema
> >shell specializations and modules.
> >  -If domain and specialization have their own individual namespaces in
> >this case. For example, wiztask would  import task, topic and the domains
> >would all have different namespaces a could pose some potential issues with
> >regards to stylesheets and conref with XSLT 1.0 processors.
> >  - This method would also have an impact on the architecture of the XML
> >Schemas. Currently, we attempt to use XML Schema inheritance to help
> >    validate the new XML Schema specialization with the hope that XS 1.1
> >will resolve a lot, if not all, of the issues regarding inheritance today.
> >    XML Schema inheritance can only apply to schemas in the same namespace
> >or null (no) namespace.  This would mean that the XML Schemas
> >    would have to be specialized without XML Schema inheritance.
> >
> >[1]http://www.ietf.org/rfc/rfc3121.txt
> >
> >Kind regards,
> >Eric
> >Eric A. Sirois
> >Staff Software Developer
> >DB2 Universal Database - DBA XML Tools Development
> >IBM Canada Ltd. - Toronto Software Lab
> >Email: esirois@ca.ibm.com
> >Phone:(905) 413-2841
> >Blue Pages (Internal)
>