[xml-dev] RE: Namespaces Best Practice

[Paul Spencer <paul.spencer@alphaxml.com>]

I'm late coming to this thread, but am I the only one to disagree with point
1? (I agree totally with 2.)

Take a typical document submitted to UK Government (my area, by the
principles apply elsewhere). This will have a document payload that will
generally meet requirement 1. It will have a single default namespace
defined in its document element. If it uses other namespaces, the bindings
will probably be defined here as well. This is then wrapped in an envelope.
This will also use a default namespace, and will itself contain a digital
signature in the XML Signature namespace (again, used as a default for this
part of the document). So the compound document has three distinct parts -
the envelope, the signature and the payload. It is both unnecessary and
confusing to declare all the namespaces in the document element of the
envelope and prefix all elements except those in a single default. Indeed,
it is positively harmful as the envelope will be stripped off and thrown
away before the payload is processed (do you keep the envelope when you get
a letter from the taxman?). Arguably, we could qualify every element of the
signature, but why not define a new default for this? After all, it is a
well-bounded section of the document.

So these "compound documents" definitely should have multiple default
namespaces defined for different parts of the document. What I would not do
is specify bindings at random through the document. I guess that is what
Jonathan is referring to.

Paul Spencer
CTO, alphaXML Ltd
alphaXML is recruiting XML Consultants and Developers
+44 (0)1491 630053
http://www.alphaxml.com


> -----Original Message-----
> From: Jonathan Borden [mailto:jborden@mediaone.net]
> Sent: 26 August 2001 19:56
> To: xml-dev@lists.xml.org
> Subject: Namespaces Best Practice
>
>
> Wow! I return from vacation to find such discussions of Namespaces x
> Schemas. It has been quite difficult for me to follow/reconstruct
> the thread
> of these arguments.
>
> Back to basics.
>
> It is a plain fact that the vast majority of major XML parsers as well as
> significant XML related specifications such as XSLT, XHTML, XLink, XSD,
> RELAXNG, Schematron etc. are XML Namespace aware. Love em or hate em XML
> Namespaces are here to stay and we are best to define namespace best
> practices.
>
> 1) An XML Namespaces best practice for document/application design is to
> define all namespace prefix bindings at the document (root)
> element context.
>
> 2) Use of XML Namespaces is optional in XML document and application
> design - however - it is a best practice to either use or not use XML
> namespaces in a single document format/application. That is, if XML
> Namespaces are to be used, it is a best practice to qualify all elements.
>
> 1) and 2) are related. Taken together, a document composed of elements
> qualified by multiple namespaces should have a single
> _unprefixed_ namespace
> and multiple prefixed namespaces. By defining the namespace - prefix
> bindings at the document (root) element, it is easy for both people and
> applications to understand the namespace structure of a document.
> Unqualified elements confuse the picture because its not immediately clear
> if they are intended to be qualified by the namespace associated with the
> empty prefix (i.e. unprefixed) or not qualified without scanning the
> namespace bindings in the element's attributes. This breaks 1). To keep
> things simple, it is best to either use or not use namespaces, but mixing
> and matching is as frought with problems as is binding the same prefix to
> different namespaces in different places within the same document.
>
> Jonathan
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>