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

Re: Namespace Comments (and dtd encoding)

  • From: MURATA Makoto <murata@a...>
  • To: xml-dev@i...
  • Date: Thu, 06 Aug 1998 11:54:50 +0900

dtd encoding
David G. Durand wrote:
> Well, it's not ugly, it allows re-use of prefixes without creating
> conflicts. This is the point of a local scoping mechanism. A prefix is
> essentially a variable, bound to a URI. the draft allows these variables to
> be rebound within limite hierachically nested scopes (just like all modern
> programming languages). These scopes are in one-to-one correspondence with
> the element structure of a document, which for documents is the most
> relevant hierarchy.
> 
> It's true that DTDs cannot be aware of this right now, but it's also true
> that local scoping is most useful incases where people want to add markup
> to existing document intances (a key scenario for namespaces). It's also
> true that after such dynamic markup, DTD validation is going to fail
> anyway.

As a member of the WG, I have been involved.  I have agreed on colonization, 
and have always believed that colonization provides a good basis for 
the namespace extension.  Now that we have local scoping and declaration by 
attributes, I start to wonder.  (Skip the rest of this message if you 
do not want to hear.)

Historically, we have always assumed that it should be possible to 
validate an XML document with namespaces with validating parsers of XML 1.0.  
This is not the case, any more.  Since the same prefix can be bound to 
different namespaces, it is no longer possible to construct an equivalent 
XML 1.0 DTD from a collection of namespace-schema pairs.  Then, what is 
the point of using prefixes?  In my understanding, one reason that we 
chose colonization rather than reserved attributes is validation by XML 1.0 
parsers.  This reason no longer exists. (Note: The other reason was 
qualification of attributes.)  

Declaration of namespaces are inherited.  But we also want to have 
inheritance of prefixes in the future.  That is, we would like an 
element to inherit prefixes from superior elements.  Thus, we will 
have complicated interaction of two types of inheritance.  For example, 
it will become possible for an element to inherit a prefix and not to 
inherit a namespace dcl.  One could argue that these two should always 
be in sync, but then what is the point of having the two?  It would have 
been a lot simpler if we had introduced a reserved attribute for specifying 
the namespace of the element.


Makoto
 
Fuji Xerox Information Systems
 
Tel: +81-44-812-7230   Fax: +81-44-812-7231
E-mail: murata@a...

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


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.