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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Fw: Namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: David Megginson <david@megginson.com>
  • To: "XML List" <xml-dev@ic.ac.uk>
  • Date: Thu, 4 Feb 1999 06:42:28 -0500 (EST)

Oren Ben-Kiki writes:

 > Question:
 > 
 > Is it possible to recast the namespace recommendation as a
 > transformation from an XML tree with 'xmlns' attributes and '...:'
 > prefixes into a tree which doesn't have them, but with modified
 > element and attribute names, such that the semantics of the
 > resulting tree under the rest of the relevant recommendations
 > (ignoring namespaces) is preserved?

Yes -- this is exactly how most people are already working with
namespaces.  It's a well-proven technique for working with
architectural forms in SGML (except that architectural forms allow 0-n
while namespaces allow exactly 1).

 > One would of course have to pass the DTDs (or other schema files)
 > through the same transformation.

No -- the DTD disappears after the initial parse; it is used to
validate the surface structure of the original document, but is not
part of the transformation.  The point, though, is that this
transformation occurs only in memory (or in database) -- if you write
it back out as XML, you have to shove prefixes back on again (they
don't have to be the same, since the prefix is just fluff).

 > Note that this may require defining a textual form for the
 > transformed tree (using "...^...", or "{..}..", or whatever).

That's one alternative; the other is to make names into the equivalent 
of

  public interface Name {
    public abstract String getURIPart ();
    public abstract String getLocalPart ();    
  }

Personally, I'm partial to using a simple string with the space
character, as in

  "http://www.megginson.com/ns/ foo"

Others have different preferences.  Simple concatentation will not
work, because {http://www.foo.com/foo}bar and
{http://www.foo.com/}foobar would not be properly distinguished.

 > If so, then we'll have a clear definition of just how to add a
 > namespace processor on top of a normal XML processor. The reverse
 > transformation could be used for emitting XML trees. The rest of
 > the XML standards could pretty much ignore namespaces
 > altogether. The endless threads of "what are namespaces this week"
 > would go away. Yes, I know, I'm dreaming (or raving :-)

No, you're awake, and you're right -- it's *really* that easy.  I
imagine that Tim Bray is probably slapping his forehead right now
yelling "DUH!", and that James Clark is probably doing whatever the
polite English equivalent is.


All the best,


David

-- 
David Megginson                 david@megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


  • References:



 

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

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