[
Lists Home |
Date Index |
Thread Index
]
> >In fact, I think it would be most
> >useful to say that both entity expansion and XInclude processing should
> >happen before XPath evaluation.
>
> I think I'll add language stating that those should happen before XPath
> evaluation - but there are some issues there. Not all parsers expand all
> entities, and XML 1.0 explicitly permits that. Similarly, many parsers
> don't speak XInclude, and the processing model for XInclude isn't exactly
> clear. Overall I think I'll state those requirements and require xpath()
> processors to report an error if they encounter either an unresolved entity
> or an unresolved XInclude. That could get very weirdly messy otherwise.
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.
--
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
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html
|
