Lists Home |
Date Index |
> At 10:11 AM 10/26/2002 -0600, Uche Ogbuji wrote:
> >Maybe your idea will work for the XInclude part, though I think it's
> >likely to
> >be messy either way. However wording that says "xpath() processors must
> >report an error if they encounter either an unresolved entity" is not really
> >meaningful. You rightly couch your draft mostly by reference to XPath, and
> >XPath has no concept of an XML entity (besides the sliver in
> >unparsed-entity-uri(). I think it's not really meaningful, then to say that
> >an XPath processor could encounter an unresolved entity.
> It's not meaningful to the XPath processor itself, but it could plausibly
> be triggered by an unparsed entity report from the parser feeding the XPath
> Plausible doesn't seem good enough in this case, so I'm leaning toward a
> simple warning in the document that XPath resolution may return varying
> results depending on the parser used to feed the XPath processor.
If I had a vote, I'd vote for this. Fiats on lower-level ambiguities would
only tend to smirch the neatness of your spec.
> I could
> alternately specify that entity resolution must be performed before the
> XPath processor, but that feels like my higher-level spec is reaching down
> a few levels into the murk.
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork