[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]