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

Re: More Parsers Questions

  • From: "David Brownell" <david-b@p...>
  • To: "Richard Tobin" <richard@c...>, <xml-dev@x...>
  • Date: Fri, 16 Jun 2000 10:01:34 -0700

questions on ll parsers
> >Question 2. Test '../sun/invalid/pe01.xml'
> 
> You're right, that test is mistaken.  There is no PE ref in pe01.dtd,
> so the question of whether the parameter entity is well-formed does not
> arise.
> 
> This has been reported to Oasis and will no doubt be fixed in a new
> release of the tests.

This test is classified as "error", meaning that some parsers _may_
report errors (as below).  It's not an "invalid" case.  Go to the
very end of the OASIS test report (draft1 of last July); that's where
you'll find it listed and described (section 2.8, "pe01").

Don't be deceived by the file name ("...invalid...") since **not one** of
the file names is definitive with respect to the test case classification.

That's not even a consideration; it'd not be maintainable over time.
Classifications can change whenever W3C comes out with errata to force
an interpretation change, or when a spec interpretation bug is found.
(Like in this case, _very_ early on.)  Names change with difficulty,
since they're used in too many places (CVS, test documentation, older
copies of the test suite, wetware, etc).

[
    Perhaps this should be in a FAQ ... if I put my copy of
    the tests into SourceForge CVS (so they can be maintained),
    would some folk be interested in helping to maintain such
    stuff on behalf of the community?  (I may do that anyway.)
]


> > Second if we ignore that ...
> 
> Then you get into a confusing area.  The constraint that external PEs
> must match markupdecl* only makes sense if external PEs can only
> appear where declarations can appear, and there is no such rule.  And
> if there were such a rule, the constraint would be unnecessary. 

I seem to recall discussing related issues with several other parser
writers.  Section 4.3.2 defines well formed entities, and 2.8 (para
just before [30]) agree on the "markupdecl" aspect, which is good since
optional text decls are key support for character encoding determination.

But there appeared to be no requirement (WFC, VC, etc) that parsers
test such an expectation _except_ when they include such entities.

And how could you test it?  What set of PE declarations should you
make available in any "is it well formed as markup" test parse, for
starters?  They can affect WFness of the entity you're testing...

In consequence, stuff like <![%PE;[ <!----> ]> "should" use internal
PEs only; "for interoperability" ... in case a parser actually tries
to test such stuff.

- Dave



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

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.