[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: System URIs
/ Rob Lugt <roblugt@elcel.com> was heard to say: | >what I thought the SAX spec demanded. Skimming for that statement, the | >closest thing I find is: | > | > If the system identifier is a URL, the SAX parser must resolve it | > fully before reporting it to the application. | > | >But I think that's referring to what the entityResolver() returns, not | >what it must be given. | > | | This is the phrase I was referring to. If you read the surrounding context, | especially the preamble for EntityResolver() you will see that, from the SAX | perspective, the implementer of EntityResolver *is* the application. So the | EntityResolver must be given a resolved, absolute URL. At the very least, it's ambiguously worded. | >Mumble. I'm not sure I think it's within our scope to dictate what a | >processor does with system identifiers (or anything else) before it | >asks the catalog processor to resolve them. | | I disagree. I believe you must state exactly what the catalog entries will | be compared against. Otherwise catalog writers are working in the dark. Catalog resolution is only one possible method of entity resolution. I believe that all we can say is what happens when an XML Catalog resolver is presented with some combination of public and system identifiers or URIs. I remain of the opinion that what the surrounding application does before it queries the resolver is out of our control | >What would be really useful would be: | > resolveEntity(entityName, publicId, systemId, baseURI) | > | Agreed. That is what our internal API looks like. I bet your internal API returns a string, too. The whole idea that the resolver should return an open stream is totally bogus to me. I wish I'd been paying more attention in the SAX 0.9 days. | Perhaps because nobody had seriously considered implementing a standard XML | Catalog using SAX. It is only with experience that the shortcomings of a | design are exposed. I would hope that the SAX maintainers (is it still | David?) will be open to reasonable argument otherwise SAX is as good as | dead. I'd love to see the SAX 3.x design consider some of these issues differently, but I haven't seen that effort starting and my plate is too full to start pushing it myself; at least right now. Be seeing you, norm -- Norman.Walsh@Sun.COM | Everything has been said before, but since XML Standards Engineer | nobody every listens we have to keep going Technology Dev. Group | back and beginning all over again.--Andr\'e Sun Microsystems, Inc. | Gide
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC