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


Help: OASIS Mailing Lists Help | MarkMail Help



   Obfuscating XML with namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: Amy Lewis <amyzing@talsever.com>
  • To: xml-dev@lists.xml.org
  • Date: Sun, 08 Oct 2000 23:01:36 -0400

Why are namespace declarations allowed to appear at any level in a

Here's a well-formed (not valid because I haven't bothered to write a
schema) document (please pardon whatever my mailer does to the wrap):

<? xml version="1.0">
<foo:element xmlns:foo="http://www.foo.com/foo">

    <foo:element xmlns:foo="ftp://xml:xml@ftp.bar.net/xml/bar">
        <foo:element xmlns:foo="file:///xml namespaces/schemas/baz">
            <foo:element xmlns:foo="mailto:foo-schema@schemas-are-us.org">
                <foo:element xmlns:foo="http://www.bigbrother.gov/servlet/schema?prefix=foo&authority=wwwc"
                 foo:attribute="what namespace am I in anyway?" />


Obfuscated xml.  Tidy refuses to see any errors in it, and I don't know
of a validation service for XML instance documents that don't conform
to a schema.  So, as far as I can tell, this is legal. 
Incomprehensible (although that's partly because I'm also taking wild
advantage of W3C's tendency to interpret "URI" as "URL syntax without
URL semantics" instead of "union of URN and URL," as the standard
defines it), but legal.  I'm not even quite sure what namespace the
most internal foo:element and foo:attribute are in (I think that the
most internal element is in a different namespace than the attribute
that it contains, but I'd hate to swear to it).

This is, of course, massive silliness.  Nobody would do this, at least
not until someone establishes an "Obfuscated XML" contest.  What I'd
like to know, then, is: what is the use case for giving namespace
declarations scope?  Why did this standard not establish (as, for
instance, the Common XML spec recommends, which is what started me
thinking about this) that declarations must go in the prefix?

Is this, perhaps, related to the import/include stuff?  If so, is it
really required?  Could import/include be implemented in such a way
that the namespaces had to have document-scope unique prefixes?

And while I'm ranting, I'll explain the comments about URI above: the
URI spec says that URI is the union of URN and URL.  URL specifications
are multiple; one for each scheme.  They always specify semantics (how
to locate) as well as syntax (the form of the string).  So, is a URL
that doesn't have the semantics of a URL really a URL?

BTW, it seems as though it would be possible to register, with IETF or
the current guardians of name purity, a urn scheme such as the
Someone would have to take the scheme through the registry process, but
could establish that the rules for the namespace are: use a domain name
that you control, first level is a date in yyyymmdd format (this means
that boo.com is identifiable, no matter who owns it today), and after
that is up to you.  And then one could establish a directory service to
contain all the schemas that someone wanted to upload, for that matter
(either on a central server to start, or using a distributed system for
robustness).  Well, side note.  Since W3C seems really allergic to the
idea of allowing any semantic meaning be attached to namespaces, and in
love with the misuse of the term URI (the HTML validator invites people
to type in a URI, not a URL ... I have a strong suspicion that any URI
that isn't a URL, and moreover a URL in the http or ftp schemes, will
be a bit hard to find ... it didn't find my urn:isbn entry, although I
had the book right in front of the monitor ...), it seems as though
such a scheme would be attractive, if only because it has the advantage
of being conformant with the URI and URN standards.

Late night babble.  The major point is: why aren't namespace
declarations required to be unique per-document?

Amelia A. Lewis          alicorn@mindspring.com          amyzing@talsever.com
A hundred thousand lemmings can't be wrong.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS