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

Re: Requirements for making DTD validation work with namespaces

  • From: james anderson <james.anderson@m...>
  • To: Wayne Steele <xmlmaster@h...>
  • Date: Fri, 18 Aug 2000 11:38:00 +0200

making dtd

The discussion becomes interesting only around "item 5" documents ...

Wayne Steele wrote:
> 
> ====================
> Requirements for making DTD validation work with namespaces
> ====================
> 
> I submit that any "special" processor behavior needs to be 100% compatible
> with XML 1.0 and the XML Namespaces Rec:
>    1. All XML 1.0 Valid documents are still Valid;
>    2. All XML 1.0 Invalid documents are still Invalid;
>    3. All namespace declarations work just as in the XML Namespaces REC
> (whether document is Valid or not)
> 
>    A frequent proposal is creation of a new definition of "Namespace-Valid"
> XML Documents.
> I also submit that, for this to work:
> 
>    4. ALL XML 1.0 documents that are Valid and conform to the XML Namespaces
> REC, are considered to be "Namespace-Valid";
>    5. SOME XML 1.0 documents that are Well-Formed, Invalid, and conform to
> the XML Namespaces REC, are considered to be "Namespace-Valid".

For this category of document only is the namespace mechanism necessary.
If you discount the dynamic aspect of namespaces, then while namespaces
may serve some explantory purpose in those cases, they are not necessary
for item 1/2 documents. For those documents, decoding with respect to
names is concerned with identity only. For which xml 1.0 suffices. It is
only with those documents for which the issue is disambiguity - those
under "item 5", those for which more than one encoded tag would map to a
given symbol, that namespaces are even necessary.


> 
> I, for one, am not interested in any scheme for integrating DTDs and
> Namespaces unless in adheres to all five requirements, above.
> 
> Sadly, the leading candidates seem to be:
>    1. Ignore the whole problem, and hope it goes away
>    2. Nested Parameter Entities, as used in the DTD for XML Schemas

The mechanism to which I alluded below neither ignores the problem nor
does it entail parameter entities, and it conforms to three of the five
constraints. Item 5 contradicts 1 and 2 and it doesn't make sense to
implement both.
> 
> -Wayne Steele
> 
> >From: james anderson <james.anderson@m...>
> >
> >If one were expect a processor to implement this mechanism, then one
> >could just as well expect a processor to implement the mechanism which
> >is already implied by the namespace spec. Namely, to observe attribute
> >default bindings for namespace attributes when reading the dtd. If
> >specified in the internal subset for the root element of a dtd fragment
> >which is described externally, the encoding is not significantly more
> >complex then the implicit qualification proposed here. It also requires
> >just implementing things which are already described...


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.