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:
| 1)  The draft specification (17 May) Section 5.x has several references to
| the *normalized* value of the systemId attribute, but the specification does
| not contain details of the normalization algorithm.  I presume this involves
| the escaping of illegal URI characters as described in XML 1.0, 4.2.2
| External Entities [1].

Yes. And attribute value normalization will also have occurred.

| a)  It might be helpful if the specification points out that no attempt
| should be made to normalize relative system URIs into absolute URIs

This is a little subtle. The strings on the "left hand side" of
system, uri, delegateSystem, and delegateURI entry types are just
strings. It certainly is the case that no attempt will be made to
normalize them. I don't think the spec needs to say this, but I could
be persuaded otherwise.

If you mean strings on the "rigth hand side", those are never relative
URIs (even if they're relative in the catalog). They are always
resolved with respect to the xml:base that's in effect at the time.

| b)  The committee should consider disallowing relative URIs in the systemId
| and systemIdStartString parameters.

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

So I think it would be reasonable and appropriate for this declaration:

  <!DOCTYPE book SYSTEM "book.dtd">

to match this entry

  <system systemId="book.dtd" uri="http://example.com/book.dtd"/>

regardless of where the document or the catalog reside.

| Point (a) would be useful to aid understanding, point (b) would be useful to
| improve the performance of applications using the XML Catalog.  Performance
| could be improved because the EntityResolver would be able to skip the
| lookup of relative URIs.

The resolver should lookup whatever URI it is handed.

| The potential performance improvement could be significant if the catalog
| contains nextCatalog entries because, for relative URIs, it is likely that
| all catalog entry files will be searched without success.

I don't agree. If I had a system that passed relative URIs to the
resolver, I'd probably take advantage of it.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM   | Well-being is attained by little and little,
XML Standards Engineer | and nevertheless it is no little thing
Technology Dev. Group  | itself.--Zen of Citium
Sun Microsystems, Inc. | 


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


Powered by eList eXpress LLC