OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Public Comment


Comment from: ehennum@us.ibm.com

DITA and Namespaces

Would it makes sense to have a namespace for each DITA package?  (DITA packages include topic specializations, domain specializations, and map specializations.)

A namespace would have a number of benefits:

*  Avoiding naming collisions for elements provided by different specialization designers.  

*  Identifying the organization that owns the element design (because the organization's domain would presumably be part of the namespace URI).

*  Permitting hosting of DITA specializations within other vocabularies.

A designer might be required to provide element names that are unique within the package namespace.  If the designer chooses to use the same namespace for more than one package, the designer would be obligated to provide unique element names for all of the packages sharing the namespace.

For topic, map, and the initial DITA specializations, the TC could use the same OASIS namespace.  That wouldn't preclude other specializers from using different namespaces for different packages.

One concern is that DITA would have two mechanisms for identifying an element:  the combination of the package identifier and element name (as in "concept/conbody") from the class attribute and the combination of the package namespace and the element name.  Providing one identifier would be preferrable.  Perhaps the package name could be the preferred namespace prefix when prefixes are used.  (Maybe somewhat at odds with sharing a namespace across packages.)

One approach for declaring the package namespace might be for the DITA architecture to require a fixed xmlns attribute for each element declaring the default namespace.  That way, processes can determine the package namespace by looking at the xmlns attribute, either in the DTD or Schema for a validated document or in the document itself for a normalized document (validated attributes copied in).

In the DTD design pattern, that approach could be implemented by declaring an entity at the top of the package definition module with the package namespace value and adding the xmlns attribute to the universal attributes.  The shell DTD could add additional prefixed namespace attributes if needed to prevent collisions when packages are assembled.

Any issues in that approach with inherited attributes (particularly architectural attributes such as class)?

Anyway, some additional long term benefits of package namespaces:

*  The package URI could be used as a key for finding the package distribution (when checking for updates, for instance).

*  The combination of the package URI and element name could be used as an element URI for making semantic assertions about the element (in RDF, for instance).  When processing the content of the element, semantic processors could use these assertions to find content of interest.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]