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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Namespace handling in XML Processors

[ Lists Home | Date Index | Thread Index ]
  • From: Marc.McDonald@Design-Intelligence.com
  • To: xml-dev@ic.ac.uk, eliot@isogen.com
  • Date: Mon, 30 Aug 1999 15:51:48 -0700

I pretty much second what Elliot has said on this subject. Namespaces
basically do nothing but sow confusion, as noted in previous message threads
about namespaces and validation.

As a namespace declaration is a URI and doesn't have the option of a URL,
there is no way for it refer to a DTD or schema defintion.  So, the
namespace prefix merely differentiates 2 names foo:bar and zoo:bar.

But, foo:bar and zoo:bar may be the same if the URI's are the same. It is
not enough to compare prefixes, you must compare URIs. And the idea of
equivalent URIs would render even that comparision inaccurate. So the best
you can say is that foo:bar and foo:bar refer to the same element and
foo:bar and zoo:bar may refer to different elements. But, you can't
determine what the valid members of foo or zoo are.

Adding validation really makes it messy. If the document using the DTD uses
namespace prefixes, then the DTD must use the same namespace prefixes
(foo:bar is not the same as bar). There are no declarations for a DTD to
define a default namespace. 

So, for validation, standard prefixes must be established for namespaces
(the document and DTD must use same prefixes). Of course the prefixes could
collide and then we're back in the same boat as before. 

I truly question the value of namespaces without association with some DTD
or schema. They purport to resolve ambiguity, but only do it syntically -
there is no identification of what each element is a member of. The problem
is punted off to the application, which somehow must assign meaning to the
URIs. In doing so, validation is thrown to the wind - we might as well
redefine XML to only parse well-formed documents and toss the DTD baggage.

Through associating a URI with a schema or DTD such identication can be
added. So why not do it as a optional parameter, add declaration of default
namespaces to DTDs/Schemas, and get it done with?

(I know DTDs just provide a content syntax and not a full semantic meaning,
but at least syntactic validity can be performed. I can tell if an element
is not part of a DTD (unless it makes use of ANY of course))

All right, a new namespace firestorm begins ;)


Marc B. McDonald
Principal Software Scientist
 <<...>> 
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA  98101
marc.mcdonald@design-intelligence.com
Ph: 206.343-7797
Fax: 206.343.7750

http://www.design-intelligence.com



> ----------
> From: 	W. Eliot Kimber[SMTP:eliot@isogen.com]
> Sent: 	Sunday, August 29, 1999 10:46 AM
> To: 	xml-dev
> Subject: 	Re: Namespace handling in XML Processors
> 
> schen@falconwing.com wrote:
> > 
> > Speaking of namespaces,
> > 
> > It's very confusing as to what is regarded as correct behavior by XML
> > processors when encountering a document with namespaces.
> > All the standard seems to do is to allow use of the same element names
> > without conflict.
> 
> No--it allows you to construct long, guaranteed unique element type
> names where part of the name (the base bit) is obviously syntactically
> separated from the first bit that guarantees uniqueness. But the element
> type name is the full-qualified name.  Therefore, there is no general
> sense in which to names that happen to have the same base part are the
> "same", any more than two machines named "spock" from different IP
> domains are the "same". They are just different names.
>  
> > So two questions:
> > 
> > 1) If an XML processor was semantically interpreting an XML document but
> > encounters an unknown namespace, is it mandated to ignore all elements
> and
> > attributes in that namespace?  I thought this was the case, but after
> > re-reading the standard I see it's not defined.  If this is not
> > standardized, can anyone say what is currently the common practice?
> 
> No processing can or should be mandidated by any 
>  
> > 2) How should a validating XML parser deal with namespaces?  This
> doesn't
> > seem to be defined very clearly.  I can see that we can include
> namespace
> > declarations in the DTD external and internal subsets, so I guess that
> if
> > I have a document mixing two namespaces I would have the external DTD
> > point to the one for the "primary" namespace and then use the internal
> > subset to override the external DTD to provide for insertion of elements
> > and attributes using the second namespace.  But this can rapidly get out
> > of hand with mixing of even more namespaces.  Is there any better
> > mechanism for this, or are any planned?
> 
> You create a set of declarations where the namespace *prefixes* are part
> of the element type declarations.  That's the only way to do it because
> XML 1.0 validation is defined purely in terms of names as declared in
> element type and attribute list declarations.
> 
> Cheers,
> 
> E.
> 
> 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)
> 

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)






 

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

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