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: Re: [dita] Proposal for DITA namespaces

Eric Sirois wrote:

> If we use the URN RFC as the basis for a URL based namespace for a http URI
> we would have a namespace like:
> http://oasis-open.org/dita/{spec_version}/packages/{specialization}
> Another TC has used the following namespace format for their XSD
> implementation.
> http://dita.oasis-open.org/{spec_version}/packages/{specialization}
> - Where "spec_version" is the version of the specification that the current
> schema
> and "specialization" topic, task, reference, concept.  Which could also
> include the various
> domains included in the current OASIS submission.

I think this basic pattern is a good one. I would propose the following 
concrete HTTP URIs, based on my working assumption that we need exactly 
two namespaces:

- For maps: http://dita.oasis-open.org/1.0/packages/maps

- For everything else: http://dita.oasis-open.org/1.0/packages/dita-base

That is, topic, task, concept, and reference are all within a single 
vocabulary and therefore are all within the same name space. This is 
reflected by the fact that all the element types common to topic, task, 
concept, and reference are exactly the same (since they all use the same 
declaration sets). Also, my initial experiments suggests that having 
different namespaces for task/concept/reference is neither useful nor 

That is, the question is not "is this document a task?" but "Is this 
document a DITA document?".

This approach also appears to require the least amount of modification 
to the existing XSD schema files. The only change I've had to make 
beyond adding the "targetNamespace" declaration to the top-level XSD 
files, is eliminating the task.xsd, concept.xsd, and reference.xsd 
files, replacing them with a single dita-base.xsd. This reflects the 
basic principle that there should be exactly one XSD instance for a 
given namespace. Since the only difference between the three specialized 
XSD files is what they *don't* include, the union of them is 
functionally equivalent to them individually for a given root element 
(that is, the rules for task, concept, and reference are not changed in 
any way).


W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122


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