[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
productive.
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).
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
eliot@innodata-isogen.com
www.innodata-isogen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]