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

Re: SAX2: Namespace Processing and NSUtils helper class

  • From: Ray Whitmer <ray@x...>
  • To: Steinar Bang <sb@m...>
  • Date: Thu, 16 Dec 1999 09:58:39 -0700 (MST)

Re: SAX2: Namespace Processing and NSUtils helper class
On 16 Dec 1999, Steinar Bang wrote:

> >>>>> "Didier PH Martin" <martind@n...>:
> 
> > HI Steinar,
> > Steinar said:
> > But what if the handling of stuff from different namespaces is
> > intermingled...?  Hm...
> 
> > Didier reply:
> > Can you be more explicit? Where precisely do you see the problem?
> 
> My problem is that I don't see clearly how people are going to use
> namespaces.  That's why I put a "Hm..." there.

I think of it as borrowing a few words of German into my English 
vocabulary to describe things that are already well-said.  American
English is already a great mixture of things from other languages.

If I see that some credible company has a good definition people
are using, I will use their definition.

>From a programming perspective, as with Java classes, I think of
the namespace together with the local name as the only good identifier
of the element.  Separately, either the namespace or the name are
not very useful to me once I live in a mixed environment.  I always
want to be certain, which is the way I program Java, as well.  In
Java, I frequently get multiple classes in the same environment with
the same name, but with the namespaces, I always know exactly which
one I am using.

The DOM spec chose to represent them as separate strings rather than
joining them in a single universal name, which for my use cases would
have been simpler to use.  So I am about 50-50 whether to choose
to do it the same way as DOM did, or whether to do it the more-
convenient way for my applications.  But others obviously don't
find this more convenient.

> I suspect that people are going to intermingle stuff from different
> namespaces, in a way that'll make processing hard.
> 
> Will stuff from different namespaces always have the same semantics?
> Or should I expect seperate processesing depending on the context?
> 

Remember, you still have a DTD or some kind of content model telling
how the objects go together, which might be unique for your use,
even if some of the elements are standardized elsewhere.  Any particular
application or DTD still chooses what is legal (or if there are sections
where anything is allowed as some sort of blind inclusion, it is passed
to another processor that presumably will understand it).

That's how I think they will be used, anyway.

Ray Whitmer
ray@x...


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 unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.