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: Namespaces Best Practice



Jonathan Borden wrote:
> Love em or hate em XML
> Namespaces are here to stay and we are best to define namespace best
> practices.

I think you identify a good, conservative set of conventions.

> 1) An XML Namespaces best practice for document/application design is to
> define all namespace prefix bindings at the document (root)
> element context.

I pretty much always do this when manually creating documents. Sometimes it
can be more difficult or awkward to do so when programmatically creating
documents. Using xsl:copy-of in the middle of a stylesheet when you don't
statically know the namespaces you'll encounter, etc. I suppose you could
run into similar issues with other types of serial transformations, not
being able to back up to the root element. I wonder: was this one of the
reasons why Namespaces were not made to be simply global within a given
document--streaming?

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

Yep. The only reasonable exception I can think of off-hand are things like
XSLT's literal result elements, where elements serve as literal
representations of some other elements, on some level. (Another example
would be found in our XML query language, which uses something like literal
result elements to specify query constraints.) Are there any other
reasonable exceptions? We've heard about the desire to augment namespaces
using local element types and NUNs, but I think that is an example of
something that firmly goes against the spirit of this rule, rather than
being able to be framed as an exception to it.

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

Shouldn't this be labeled convention #3? There's nothing in #1 or #2 that
would forbid me from *always* using prefixes, right? In any case, I would
personally be more neutral on whether people should or shouldn't use a
default namespace. It seems to be neither here nor there (although,
instictively, I think people are more apt to override a default namespace
than to override a specific prefix, thus breaking rule #1).

Someone said never using a prefix is isomorphic to always using a prefix.
Beyond a simplistic comparison, this is not true. I can't follow the above
conventions if I never use prefixes, but I can follow them if I always use
prefixes.

Evan Lenz
XYZFind Corp.