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

Re: Namespace prefixes optional?

  • From: David Megginson <david@m...>
  • To: xml-dev <xml-dev@i...>
  • Date: 07 Jan 2000 08:55:58 -0500

perl preserve namespace
james anderson <James.Anderson@m...> writes:

> a. How does one do attribute defaulting in situations where the
> namespaces matter. That is, in situations where one can't just treat
> the document as if it were "xml-1.0-plain".

Declare the attribute -- it is irrelevant whether Namespaces matter or
not.  Or is your question "how can you preserve an attribute default
after a round trip through a processor that doesn't preserve the
original Namespace prefixes"?

That said, I think that attribute defaulting is a bad idea in most
cases, because (especially for data exchange) it opens up all kinds of
potential bugs and, more importantly, security holes.

> b. How can one uphold the constraint, that the set of valid
> "xml-1.0+namespaces" documents is identical with the set of valid
> "xml-1.0-plain" documents. Mr Waldin's question is one case in point.

I'm not sure what you mean.  

If you're using "valid" the same way as the XML 1.0 spec does, then
the set of valid documents that happens to contain Namespace
declarations is a strict subset of the set of all valid XML 1.0
documents; in other words, they are not identical.

The Namespaces spec (like the RDF spec, the XHTML spec, XLink spec, or
most other specs) imposes additional constraints on a document beyond
validity or well-formedness.  It is possible to have a document that
is valid XML 1.0 but not conformant to Namespaces or RDF or XLink, and
conversely, it is possible to have a document that is well-formed but
not valid XML 1.0, but still conforms to Namespaces, RDF, or XLink
(though not XHTML, which requires validity for strict conformance).

> c. How does one specify an identity between a "name which is in no
> namespace" and a "name in a namespace as declared in a
> schema". Perhaps I'm just narrow-minded, but I sense a potential
> contradiction in this notion.

This is an interesting problem, but what does it have to do with
Namespaces?  All the Namespaces REC does is specify how to create
elements and attributes with two-part names, like you can with methods 
or variables in Perl and Java (Namespace == package).  It's very

- In plain XML 1.0, all names have a single part.

- The Namespaces REC defines a method for creating two-part names
  using conformant XML 1.0 syntax.

There are many people who wish that the Namespaces REC had set out to
do more -- perhaps to talk about what Names mean, or how they can be
identified with each-other -- but given how much noise there's been
about even the little bit that the NS REC did set out to do, I think
it's clear that it was smart not to attempt even more.

> These for starters. They follow from the root problem, that the REC
> did ratify a complete model for the domain which it describes. It
> was most disappointing to observe the extent to which the appendix
> was disavowed. Were one to have taken something of that sort
> seriously, such issues may have come to light, rather than being
> "left to the application".

For "left to the application" substitute "left to higher-level specs".
People were already preparing to start work on an XML Schema spec, and
it didn't make sense for Namespaces to do a half-assed job trying to
do part of schema's work for it and then leaving the schema people
with all kinds of constraints.  

Good specifications are layered, with each one accomplishing a single,
well defined task.  The Namespaces spec set out to answer the question
"How do you represent a two-part name in XML 1.0 syntax?", not "How do
you solve every possible problem with inheritance, identity, and
validation in XML?"

All the best,


David Megginson                 david@m...

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...)


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.
First Name
Last Name
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.