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


Norman, I see from the archives that you wrote:-
http://lists.oasis-open.org/archives/entity-resolution/200105/msg00178.html
(it would be easier for me if you included my email address on your
replies!)

>| 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 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.

>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.

>What would be really useful would be:
>  resolveEntity(entityName, publicId, systemId, baseURI)
>
Agreed.  That is what our internal API looks like.

>but when I pointed this out to the SAX maintainers, they indicated
>that changing the API was not in the cards.

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.

>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.

Perhaps the specification could allow for two different modes of processing
relative system identifiers: 'resolved' or 'literal'.  This would give the
best of both worlds: SAX implementations could implement the "resolved" mode
and others could choose the most appropriate.  Both would be correct and it
would be obvious how catalogs would interoperate.

Regards
Rob Lugt
ElCel Technology



------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: entity-resolution-comment-request@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC