OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[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