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

While I understand the reasoning, I need a namespace in order to use DITA
with Word 2003. I can create my own in the interim, but I would prefer to
use something official. 


Mary McRae 


	From: Erik Hennum [mailto:ehennum@us.ibm.com] 
	Sent: Monday, July 26, 2004 11:21 PM
	To: dita@lists.oasis-open.org
	Subject: Re: [dita] Proposal for DITA namespaces

	Honored Members of the DITA Technical Committee,
	Eric Sirois and I have been kicking around the namespaces issue
offline and would like to bring forward some considerations.
	** A typical rationale for namespaces is to support combining XML
vocabularies by preventing collisions between the element names in each
vocabulary. DITA, however, has the additional concern of preventing
collisions between specialization packages within the DITA vocabulary.
(Specializations are, in effect, vocabularies in their own right.) At a
minimum, each supplier of specialization packages should have a distinct
	** A second use of namespaces is to allow processable statements
about XML vocabularies. For instance, a RDDL file could provide a
human-readable summary of a specialization package as well as a
machine-processable listing of the document type modules, transform modules,
and documentation files for the specialization package. Similarly, by
establishing a convention that identifies elements through a combination of
the namespace for the package with the element name, it would be possible to
make RDF statements about elements. To provide a systematic approach for
identifying both specialization package resources and for making statements
about elements, each specialization package should have a distinct
	** The relationship between namespaces and DITA type inheritance
needs to be thought through carefully, both in light of good design and
support by XML Schema and XSLT implementations. In particular, with work
starting on XML Schema 1.1 and no clear statement from XSLT 2.0 on whether
XML Schema 1.1 will be supported, the design constraints aren't clear. We
don't want to institute a design for namespaces to find that no tool
supports it or that the next generation of tools will permit a better
	** In particular, the relationship between the specialization
package namespace and the package identifier in the class attribute needs to
be thought through. Ideally, the class attribute would express the element
ancestry as a list of qualified element names (where the qualifier is the
namespace prefix), so the qualified element name would be the same in the
class attribute as in other contexts. Unfortunately, to prevent collisions,
the document type must be able to assign the prefix to the namespace URI.
The namespace URI itself is stable, but the namespace URI is too verbose to
serve in the class attribute.
	** The impact of namespaces on authoring needs to be thought
through. While the ability to prevent naming collisions is crucial, many
DITA document types will assemble specializations that don't have naming
collisions. In such cases, requiring namespace prefixes on elements merely
imposes clutter on the author. We might be able to come up with a design so
the document type controls whether a specialization package has a namespace
prefix or, instead, becomes the default namespace for its elements.
Inherited attributes may pose some challenges for this goal.
	Because of these design questions and the uncertain standards and
tool environment, the TC may want to defer resolution of the namespace
issues until the next version of DITA. This approach would give the TC time
to come up with an optimal design, to push for enhancements to evolving
standards (especially for XSLT 2 to support XML Schema 1.1), and to push for
conformance by XSLT processors and other tools.
	One consequence of this deferral would be that the DTD version would
likely remain normative in the first version of DITA. While this gives DITA
the appearance of lagging behind standards, the TC could clarify that an XML
Schema implementation is available, that a normative XML Schema
implementation should make full use of the advanced type inheritance
features, and that an XML Schema implementation is likely to become
normative once support for type inheritance stabilizes in the Schema and
XSLT standards and gets widespread support in tools.
	Hoping that's useful,
	Erik Hennum
	Paul Grosso <pgrosso@arbortext.com> wrote on 07/19/2004 01:33:49 PM:
	> Though it's true that RFC 3121 defines a URN namespace for OASIS, 
	> Norm (the author of said RFC) has changed his mind on this.  See:
	> http://norman.walsh.name/2004/03/03/266NorthPleasant which Norm 
	> wrote after the W3C TAG's Web Architecture document at
	> http://www.w3.org/TR/webarch/
	> came out in favor of resolvable URIs for namespace names.  Norm
	> now suggests using http: URIs for namespace names.
	> DocBook NG uses http://docbook.org/docbook-ng .
	> DocBook V5 will probably use something analogous. 
	> paul
	> At 16:19 2004-07-16 -0400, Eric Sirois wrote:
	> >Here is quick note to formally introduce and start some
	> >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
	> >Technical Committee Work Products
	> >
	> >         The "tc" hierarchy is for work products of OASIS
	> >         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
	> >         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
	> >namespaces.
	> >
	> >Below is a list of namespaces that could apply to topic, task,
concept, and
	> >reference.
	> >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
	> >Schemas.
	> >
	> >Method - 1
	> >  -The namespace for each specialization is bound in the schema
	> >files.
	> >  -The namespace would then be assumed (chameleon effect) by all
	> >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
	> >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
	> >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
	> >    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
	> >or null (no) namespace.  This would mean that the XML Schemas
	> >    would have to be specialized without XML Schema inheritance.
	> >
	> >[1]http://www.ietf.org/rfc/rfc3121.txt
	> >
	> >Kind regards,
	> >Eric
	> >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]