Esteemed DITA TC:

In hopes that it will be useful background for deliberations about namespaces, I'd like to try to pull together the goals for namespaces that seem to have emerged on this thread:

1. We should avoid the twin risks of delaying DITA 1.0 for investigating, prototyping, and testing namespace schemes and of rushing into a namespace scheme that has to be reworked later.

Our approach now should be conservative so we can solve the problem correctly later for the long term.

2. In DITA 1.0, namespaces should be optional.

As Paul asserts, we don't want existing DITA implementers to have to take on a major rework of their content and processing.

Conversely, in environments where namespaces are required (Mary's situation with Word or Eliot's application), it should be possible to use namespaces for DITA content.

3. In DITA 2.0, namespaces should be used to identify specialization packages in the typing system for the DITA architecture

Namespaces should identify specialization packages so they can be used to match elements with processors and so we can prevent name collisions between packages created independently by different designers.

The scheme for managing type ancestry (that is, the values and processing of the class attribute) will likely have to be revised to make use of namespaces.

4. In DITA 2.0, namespaces should be used to identify DITA shell vocabularies.

Namespaces should provide a handle for the vocabularies assembled by DITA shells. That identifier makes it possible to match DITA content with the best content handler and is especially important for applications that understand a specific vocabulary rather than the DITA architecture.

The scheme for declaring the namespace for the shell vocabulary without colliding with the namespace for the root element's specialization package will need to be thought through.

I'd propose considering the following approach:

1. We document a namespace pattern to be used for core DITA and its specializations and use this pattern to document a standard namespace for each specialization package and shell provided in the core DITA distribution.

The namespace pattern might follow the pattern proposed by Eric Sirois:

http://{organizationSource}/{DITAVersion}/shell/{documentTypeBasename}

http://{organizationSource}/{DITAVersion}/package/{specializationPacka geIdentifier}

Thus, the namespaces for the core DITA distribution would follow the pattern:

http://dita.oasis-open.org/{DITAVersion}/shell/{documentTypeBasename}

http://dita.oasis-open.org/{DITAVersion}/package/{specializationPackag eIdentifier}

[ Supports Goal 2 ]

2. We don't use the documented namespaces in the DTDs or Schemas provided in the core DITA distribution.

[ Supports Goals 1 and 2 ]

3. We provide a caution that a future DITA release 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 root element.

[ Supports Goals 3 and 4 ]

4. A DITA adopter who works in an environment that requires namespaces can create a wrapper that imports the shell, applying the namespace for the shell vocabulary.

For individual topic type shells, the recommended approach might be to wrap the topic type in a dita element whose content model allows a single instance of the topic. By avoiding declaring the shell namespace for the vocabulary on the root element (which may have a specialization package namespace in the future), this approach avoids a potential source of rework.

For instance, to use a namespaced concept vocabulary, an adopter could create a new concept_ns.xsd Schema that includes concept.xsd, defining a dita element that contains the concept element and declaring the dita element to be in the http://dita.oasis-open.org/1.0/shell/concept namespace.

We wouldn't include these wrappers in the distribution because we don't encourage the namespaced approach in DITA 1.0. We document this approach as a stopgap for those who have to have namespaces before we work through a complete scheme for DITA type and vocabulary classification based on namespaces. Someone might, however, implement these wrappers based on the documentation and put them out on the DITA users's group as a helpful community extension to core DITA.

DITA doesn't have a tradition of an untyped container for map, so that corner would need to be addressed.

[ Supports Goals 1 and 2 ]

5. Applications can determine the content handler for DITA content through awareness of either the DITA shell vocabulary namespaces or the DITA class attribute.

An application could require vocabulary namespaces for DITA content and match the namespaces for the DITA shell vocabularies provided by the core distribution.

Alternatively, an application could accept non-namespace DITA content and look for a class attribute that has topic or map as the specialization package qualifier in the first position.

[ Supports Goals 1 and 2 ]

What do you think?