[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Namespace Applications

• From: Paul Prescod <paul@p...>
• To: "XML Developers' List" <xml-dev@i...>
• Date: Sat, 06 Feb 1999 11:49:58 -0600

David Megginson wrote:
> <email>paul@p...</email>
> <company>ISOGEN</company>
> <a:origin>Canada</a:origin>
> <b:origin>University of Waterloo</b:origin>
> </member>
>
> ...
> 
> The advantages of being able to come up with globally-unique names
> should be obvious:

Actually it isn't to me. The problem is now you have <a:origin> and
<b:origin> element types but you don't know what to do with them. This is
the point I keep harping about: processing expectations. Clearly
<a:origin> is supposed to be mapped either to nothing or to
<david:CountryOfOrigin> and <b:origin> is to be mapped either to nothing
or to <david:GraduatedFrom>. It seems to me that information should not be
let into my information system until it is expressed in terms that my
information system is familiar with.

What that means is that these things should be shipped with either
architectural declarations or an XSL stylesheet that lets me locally
reinterpret them. If all you want to do is make unknown elements
"disappear" you can do that without namespaces also.

> A second major advantage of namespaces is the ability to reuse
> processing code.  If I have written an event-handler/subroutine/method
> to do something useful with an HTML <table> element, then I'd like to
> reuse that for *every* document type that happens to use the HTML
> table model, even if I don't know about the document type in advance.

I can think of a variety of non-namespace ways to handle this (including
the one you pointed out). Maybe I'm over-conservative but I will not
advise my customers to depend on the namespace mechanism until there are
facilities for validating and processing them intelligently. I mean even
the most XSL-sophisticated XML editor/formatter would not recognize your
namespace-prefixed HTML element if you changed the prefix because XSL
itself does not handle it. I mean there is leading edge and there is
bleeding edge....
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"Remember, Ginger Rogers did everything that Fred Astaire did,
but she did it backwards and in high heels."
                                               --Faith Whittlesey

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Namespace Applications
    • From: james anderson <James.Anderson@m...>
  • Re: Namespace Applications
    • From: Gabe Beged-Dov <begeddov@j...>

• References:
  • Re: SAX, Java, and Namespaces (was Re: Restricted Namespaces for XML)
    • From: hpyle@a...
  • Re: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML)
    • From: Paul Prescod <paul@p...>
  • Re: SAX, Java, and Namespaces (was Re: Restricted Namespaces forXML)
    • From: David Megginson <david@m...>

• Prev by Date: Re: What Clean Specs Achieve
• Next by Date: Re: What Clean Specs Achieve
• Previous by thread: Architectural Forms and Namespaces (Was: Re: SAX, Java, and Namespaces )
• Next by thread: Re: Namespace Applications
• Index(es):
  • Date
  • Thread