[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: | Norman, I see from the archives that you wrote:- | | http://lists.oasis-open.org/archives/entity-resolution/200105/msg00171.html | | 1) I'm still not absolutely clear about the processing required for the | values of the systemId, systemIdStartString, name and uriStartString | parameters. Obviously they will be normalised in the XML 1.0 sense, but I | think they should be further normalised to escape illegal URI characters | before attempting to match with the value provided from the XML Parser to | the EntityResolver. Yes, this is a good point. I will make the spec clearer. | 2) It may be worth pointing out that all parameters that take a value | marked "uri-reference" should be normalised in the same way that system | identifiers are normalised by XML 1.0 [1]. The systemId, systemIdStartString, name, and uriStartString attributes are all going to become type 'string' later this morning. The problem with uri-reference is that I believe XML Base would require that relative URIs be made absolute with respect to the base in effect and that's not desired for those values. | 3) I was particularly interested in your answer to my question regarding | relative URIs | | >Whether or not your catalog processing application will ever receive | >relative URIs is an open question. The spec allows it (and I think it | >should), but in practice most SAX-based applications that I'm aware of | >make the URI absolute long before the resolver is called (more's the | >pity). | | I checked the SAX specification for EntityResolver and, as you suggest, it | demands that the system identifier is resolved to an absolute URI by the SAX | Parser before the EntityResolver is called. Oh, barf. Where is this written in the SAX spec? I've never noticed it in the past, I was describing what I know most common applications do, not 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 indeed a pity because it raises an interoperability issue. I was | expecting the resolver to receive the system identifier as it appeared in | the xml document (after normalisation and URI character escaping as | described in XML 1.0). I think it is important that this is clearly stated | in your specification; how else can people confidently code the catalog | entries? 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 would prefer to see an interface like: ResolveEntity(publicId, | systemId, baseUri) What would be really useful would be: resolveEntity(entityName, publicId, systemId, baseURI) but when I pointed this out to the SAX maintainers, they indicated that changing the API was not in the cards. In answer to your question, no, I don't personally (nor do I think this committee) want to be driven by inadequacies in SAX. OTOH, SAX is the single largest parser API out there and writing a spec that cannot be implemented by SAX could raise a significant barrier to acceptance. And I think (personally) that widespread adoption of catalog-based resolvers is an important goal. Be seeing you, norm -- Norman.Walsh@Sun.COM | You look wise. Pray correct that XML Standards Engineer | error.--Charles Lamb Technology Dev. Group | Sun Microsystems, Inc. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC