RE: [xml-dev] RE: Namespaces Best Practice

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Composition of information from multiple sources was one of the important
arguments in favor of the namespace declaration mechanism we currently have.

For example, suppose I'm incorporating a list of things into my document,
and each member of the list is an element coming from a different piece of
software, or from a different document.  With the current mechanisms, each
respondent is able to provide me with an element that's closed over its
prefixes (in other words, for every prefix that appears in that element,
there can be a namespace attribute at the element's open tag).  In fact, if
this list is at the end of the document, I don't even need to remember what
namespaces were active in the enclosing document - just the prefix for the
end tag of the root element.

If, on the other hand, I were to insist on requirement 1, then I can't
release any of the document until I've seen the whole thing, because I don't
know (necessarily) what namespaces will show up in the list, so I need to be
ready to update the root element after the list has arrived.  I'll also need
(potentially) to rewrite large portions of the document to normalize the
namespace prefixes used everywhere.  So 1) is not generally good for
application development.

I don't understand 2), as it seems (to me) to confuse qualified and
prefixed.  Any name in a namespace is qualified, but not necessarily
prefixed, i.e., all prefixed names are qualified, but not all qualified
names are prefixed.  I'm not sure if 2 is talking about prefixed or
qualified anywhere.

Matthew

> -----Original Message-----
> From: Paul Spencer [mailto:paul.spencer@alphaxml.com]
> Sent: Wednesday, September 19, 2001 9:32 AM
> To: Jonathan Borden; xml-dev@lists.xml.org
> Subject: [xml-dev] RE: Namespaces Best Practice
> 
> 
> 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>
> >
> >
> 
> 
> -----------------------------------------------------------------
> 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>
>