OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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


> In fact, if
> this list is at the end of the document, I don't even need to remember
> namespaces were active in the enclosing document - just the prefix for the
> end tag of the root element.

Of course each source of information may choose entirely different and
overlapping prefixes for namespaces. Such a document is difficult for people
to read. Of course software ought care less about which prefixes go with
each namespace, indeed it should be generally possible to write, say,
SAX/XSLT type code that is unaware of how or where a namespace is declared
i.e. to use only local-name() and namespace-uri().

> 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
> know (necessarily) what namespaces will show up in the list, so I need to
> ready to update the root element after the list has arrived.

1) is a best practice, not a requirement. I am not calling to change the XML
Namespaces REC.

Streaming applications may have trouble normalizing XML namespaces - indeed
that is the reason to -try- and provide source XML documents in normalized
fashion i.e. to declare prefixes at the root element context.

On the other hand software such as XSLT processors -usually- read process
then write, and in such cases namespace normalization is straighforward.

> 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 suppose it depends on what it is worth to you in order to make your
documents readable by people. If your document is not intended to be looked
at by a person, nor stored for a long period of time, rather a transient
piece of machine to machine communication, then it might not be worthwile
spending much energy on cleaning it up.

> 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.

> > >
> > > 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.
> > >

As I said. I think it is totally fine to use namespace qualified but
_unprefixed_ elements because they are easily readable by people yet
machines are told which namespace name they are qualified by. If the default
namespace decl is right up top, then it is really easy for people to see
what namespace name qualifies the unprefixed elements, so everybody -should-
be happy.

This should be seen as a style guideline which should be followed unless
there is a good and clear reason not to. that said there are good and clear
reasons not to follow this style in specific situations.