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: Proposal for DITA namespaces

Hello TC Members,

Here is quick note to formally introduce and start some discussions
regarding namespaces for DITA XML Schemas.

As per the RFC 3121(A URN Namespace for OASIS) [1] from IETF below you will
find some of the namespace that
could be applied to DITA XML Schemas.

Here is a snippet the RCF that is of interest to the TC:
The RCF general structure for Technical Committee is the following:
Technical Committee Work Products

         The "tc" hierarchy is for work products of OASIS Technical
         Committees.  The general structure of the NSS in the tc
         hierarchy has the form:


         where "tc-id" is a unique identifier for the Technical
         Committee, and the remaining fields are assigned as per the
         specification hierarchy.

Namespace suggestions:
Here are two namespaces that Eliot has been using for his modified version
the XML Schemas for his application xiruss-t
map - urn:oasis:names:tc:dita:map
ditabase - urn:oasis:names:tc:dita:base
I believe in this case that the four base XML Schema all have the same

Below is a list of namespaces that could apply to topic, task, concept, and
topic - urn:oasis:names:tc:dita:topic
task - urn:oasis:names:tc:dita:task
concept  - urn:oasis:names:tc:dita:concept
reference - urn:oasis:names:tc:dita:reference

Domains could have their own namespaces (as part of Method 2 - see below).
highlight-domain - urn:oasis:names:tc:dita:highlight-domain
programming-domain urn:oasis:names:tc:dita:programming-domain
ui-domain - urn:oasis:names:tc:dita:ui-domain
utilities-domain - urn:oasis:names:tc:dita:utilities-domain
software-domain - urn:oasis:names:tc:dita:software-domain

There are a couple methods in which a namespaces can be bound to the XML

Method - 1
  -The namespace for each specialization is bound in the schema shell
  -The namespace would then be assumed (chameleon effect) by all included
schemas in the primary XML Schema and would not
affect specialization. For example, wiztask which includes task, topic and
the domains would all have the same namespace.
With this method we can make full use of XML Schema inheritance to create
new specialization.  Inheritance helps developers validate
new DITA specialization when validating the XML Schema rather that manually
checking whether or not a new specialization follows the
DITA specialization rules.

Method - 2
  -The namespace for each specialization is bound in the in the schema
shell specializations and modules.
  -If domain and specialization have their own individual namespaces in
this case. For example, wiztask would  import task, topic and the domains
would all have different namespaces a could pose some potential issues with
regards to stylesheets and conref with XSLT 1.0 processors.
  - This method would also have an impact on the architecture of the XML
Schemas. Currently, we attempt to use XML Schema inheritance to help
    validate the new XML Schema specialization with the hope that XS 1.1
will resolve a lot, if not all, of the issues regarding inheritance today.
    XML Schema inheritance can only apply to schemas in the same namespace
or null (no) namespace.  This would mean that the XML Schemas
    would have to be specialized without XML Schema inheritance.


Kind regards,
Eric A. Sirois
Staff Software Developer
DB2 Universal Database - DBA XML Tools Development
IBM Canada Ltd. - Toronto Software Lab
Email: esirois@ca.ibm.com
Phone:(905) 413-2841
Blue Pages (Internal)

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