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