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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: DITA namespace?



There are a lot of tools that depend on namespace to associate a document with its schema or processing. DITA doesn't have a namespace right now, but we probably do need one. The issues are:

1.-would new namespaced content be backwards compatible with tools and editors?
2. could processing handle a mix of namespaced and non-namespaced DITA content?
3.  what do we tell specializers to do?

In an ideal world, it would be nice to have a separate namespace for every DITA specialization: but the issue we had with that in our previous discussion was the usability of a compound document that would include so many different namespaces, and the inability to default more than one of them.

If we can answer 1 and 2 in the positive, maybe the position for 1.1 could be:

- provide a single "dita" namespace for all base DITA markup (eg topic, task, concept, reference, various domains)
- if necessary, provide an un-namespaced version as well, for backwards compatibility with any existing tools/implementations
- tell specializers to either create their specializations in the existing "dita" namespace, or in no namespace, or in their own namespace, at their discretion (as long as the result can still be processed and edited as DITA topics based on class attributes etc.)

And defer to the future the question of whether we can overcome the technical and usability challenges involved in synchronizing namespaces and design modules in DITA, ie having the topic type or domain name as the automatic namespace for any specialization.

Michael Priestley
IBM DITA Architect
Classification Schema PDT Lead
mpriestl@ca.ibm.com


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