Namespace prefixes optional?

David Megginson david at
Fri Jan 7 13:56:50 GMT 2000

james anderson <James.Anderson at> writes:

> a. How does one do attribute defaulting in situations where the
> namespaces matter. That is, in situations where one can't just treat
> the document as if it were "xml-1.0-plain".

Declare the attribute -- it is irrelevant whether Namespaces matter or
not.  Or is your question "how can you preserve an attribute default
after a round trip through a processor that doesn't preserve the
original Namespace prefixes"?

That said, I think that attribute defaulting is a bad idea in most
cases, because (especially for data exchange) it opens up all kinds of
potential bugs and, more importantly, security holes.

> b. How can one uphold the constraint, that the set of valid
> "xml-1.0+namespaces" documents is identical with the set of valid
> "xml-1.0-plain" documents. Mr Waldin's question is one case in point.

I'm not sure what you mean.  

If you're using "valid" the same way as the XML 1.0 spec does, then
the set of valid documents that happens to contain Namespace
declarations is a strict subset of the set of all valid XML 1.0
documents; in other words, they are not identical.

The Namespaces spec (like the RDF spec, the XHTML spec, XLink spec, or
most other specs) imposes additional constraints on a document beyond
validity or well-formedness.  It is possible to have a document that
is valid XML 1.0 but not conformant to Namespaces or RDF or XLink, and
conversely, it is possible to have a document that is well-formed but
not valid XML 1.0, but still conforms to Namespaces, RDF, or XLink
(though not XHTML, which requires validity for strict conformance).

> c. How does one specify an identity between a "name which is in no
> namespace" and a "name in a namespace as declared in a
> schema". Perhaps I'm just narrow-minded, but I sense a potential
> contradiction in this notion.

This is an interesting problem, but what does it have to do with
Namespaces?  All the Namespaces REC does is specify how to create
elements and attributes with two-part names, like you can with methods 
or variables in Perl and Java (Namespace == package).  It's very

- In plain XML 1.0, all names have a single part.

- The Namespaces REC defines a method for creating two-part names
  using conformant XML 1.0 syntax.

There are many people who wish that the Namespaces REC had set out to
do more -- perhaps to talk about what Names mean, or how they can be
identified with each-other -- but given how much noise there's been
about even the little bit that the NS REC did set out to do, I think
it's clear that it was smart not to attempt even more.

> These for starters. They follow from the root problem, that the REC
> did ratify a complete model for the domain which it describes. It
> was most disappointing to observe the extent to which the appendix
> was disavowed. Were one to have taken something of that sort
> seriously, such issues may have come to light, rather than being
> "left to the application".

For "left to the application" substitute "left to higher-level specs".
People were already preparing to start work on an XML Schema spec, and
it didn't make sense for Namespaces to do a half-assed job trying to
do part of schema's work for it and then leaving the schema people
with all kinds of constraints.  

Good specifications are layered, with each one accomplishing a single,
well defined task.  The Namespaces spec set out to answer the question
"How do you represent a two-part name in XML 1.0 syntax?", not "How do
you solve every possible problem with inheritance, identity, and
validation in XML?"

All the best,


David Megginson                 david at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list