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


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.

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

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.

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?

My preference would be for system identifiers to *not* be resolved to
absolute URIs before calling the catalog resolver.  I understand this would
cause problems for SAX-based implementations, but it does seem that SAX has
room to improve in this area*.  Do you want the XML Catalogs spec to be
driven by inadequacies in SAX?

Regards
Rob Lugt
ElCel Technology

[1] http://www.w3.org/TR/REC-xml#sec-external-ent
[*] I would prefer to see an interface like: ResolveEntity(publicId,
systemId, baseUri)



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