Namespace resolution

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

Esteemed DITA TC:

As a possible lead-in to discussion of namespaces (slippery little devils), I wanted to summarize my understanding of the resolution that Eliot discovered. Please correct as needed:

1. The TC will define a distinct namespace for each specialization package and document type shell in OASIS DITA (see the candidate list below).

2. In the first release, the DITA DTD and Schema document types will _not_ be distributed with namespace attributes that declare these namespaces directly.

3. Specializers are encouraged to define a distinct namespace for each specialization package and document type shell that they create.

4. Processors are encouraged to treat specialization package identifiers and specialization package namespaces as interchangeable identifiers.

5. DITA adopters may use the namespace for the shell document type to identify a document during authoring or processing but must recognize that the shell namespace does not identify the type of the document element.

Because a topic type can be used in multiple shells (for instance, shells assembling different combinations of domains), the same DITA topic element could be the document element in several different document types. If the shell namespaces are declared in these documents, a topic element could belong to several different namespaces. The best solution for this problem would be to attach the namespace for the shell document type to something other than a specialization package element. Until we have that solution, people need to be aware of the ambiguity.

6. A future release of DITA may integrate namespaces more directly into the DITA type classification system. This change alone should not result in any changes to element structures or local element names but could change the way namespaces are used on the document element.

Here follows a list of candidate namespaces in the following formats proposed by Eric Sirois:

http://dita.oasis-open.org/{version}/shell/{documentTypeBasename}
http://dita.oasis-open.org/{version}/package/{specializationPackageIdentifier}

The shell document type namespaces (equivalent to *.dtd and *.xsd) might be as follows:

http://dita.oasis-open.org/1.0/shell/topic
http://dita.oasis-open.org/1.0/shell/concept
http://dita.oasis-open.org/1.0/shell/reference
http://dita.oasis-open.org/1.0/shell/task

http://dita.oasis-open.org/1.0/shell/ditabase

http://dita.oasis-open.org/1.0/shell/map

The specialization package namespaces (equivalent to *.mod and the qualifiers on the class attribute) might be as follows:

http://dita.oasis-open.org/1.0/package/topic
http://dita.oasis-open.org/1.0/package/concept
http://dita.oasis-open.org/1.0/package/reference
http://dita.oasis-open.org/1.0/package/task

http://dita.oasis-open.org/1.0/package/hi-d
http://dita.oasis-open.org/1.0/package/pr-d
http://dita.oasis-open.org/1.0/package/sw-d
http://dita.oasis-open.org/1.0/package/ui-d
http://dita.oasis-open.org/1.0/package/ut-d

http://dita.oasis-open.org/1.0/package/map
http://dita.oasis-open.org/1.0/package/mapgroup-d


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com


Eliot Kimber <ekimber@innodata-isogen.com> wrote on 08/04/2004 01:49:48 PM:

> I think that in 1.0 we can solve this problem as follows:
>
> 1. Assert that the "package/class" syntax is functionally equivalent to
> "prefix:local_name" in that the package name is taken to be a namespace
> prefix that maps to some defined namespace URI.
>
> 2. Assert that in DITA 1.0 the DITA-defined package names are "magic"
> reserved namespace prefixes and that documents do not need to delcare
> these namespaces--conforming DITA processors will assume the
> declarations of the corresponding namespaces URIs. We must define those
> URIs in the 1.0 spec and it wouldn't hurt to include them in the DITA
> schemas. But document instances would not need to declare them (that is
> DTD-only or no-schema documents would still be fine).
>
> 3. Assert that any non-DITA-defined package name must have a
> corresponding in-scope xmlns declaration that maps that package name to
> the appropriate namespace. Or, possibly, allow the package name to be
> replaced by a URI (but I don't this would have to be allowed and
> allowing it would introduce some potentially tricky syntax issues that
> are probably better avoided in 1.0).
>
> 4. Assert that DITA processors that can must expand package names to
> their URIs for the purposes of mapping classes to processing or
> validation rules (just as they would expand normal XML namespace
> prefixes). Processors that cannot do that (i.e., non-DITA-aware CSS
> renderers) just have to depend on the package prefixes being unique.
> This means that if you are creating documents with two different
> non-DITA-defined specializations, you better make sure that the local
> package names are different so your CSS style sheets will work right.