Re: XML Public Indentifier

[Daniel Veillard <veillard@redhat.com>]

On Wed, Sep 05, 2001 at 03:52:24PM -0400, Norman Walsh wrote:
> / Daniel Veillard <veillard@redhat.com> was heard to say:
> |   I also didn't got a valid answer why you decided that system identifier
> | resolution in the DOCTYPE and elsewhere in the document had to be done
> | in a different way and using a different syntax in the Catalogs !
> 
> Well, I thought my answer was valid :-)

  Hum, I don't remember seen your answer, might be my fault :-\

> 1. The external identifier has both public and system parts and this
> requires the resolver to be more sophisticated. It has to handle
> different prefer settings and the possibility of public as well as
> system delegation. For the purposes of resolution, you cannot treat a
> system identifier like a random URI.

  Look at the algorithm in 7.1.1 if you have a system identifier (which
is a requirement for XML resolution, and will occur if you don't use
the ID URN scheme) you analyze first system, rewriteSystem and delegateSystem.
  In 7.2.1 you analyze uri, rewriteURI, delegateURI and process them in
the exact same fashion unless I missed something.
  So I don't see why one "cannot treat a system identifier like a random URI"
since you actually process them in very similar ways, but force to use a
different set of catalog entries anyway. No I really fail to see why
this is the case. Why should DTD be loaded from a completely separated
space than images if the URI referencing them point to the same source.
I can't see the requirement for this.
  The only case if you keep a mirror of the system space locally but want
the match to be made on the public identifier only. This means you do not
want the Dtd URI references to be handled from that space but others resources
should. Then you can simply handle this special constraints by setting up more
specific rewriteSystem and delegateSystem for Dtd URI, without sacrifying
the beauty of rewriteSystem and delegateSystem which are life savers.

> You could, I suppose, treat a random URI like an external identifier
> with a null public id, but that would make every resolution take into
> account possibilities that cannot arise.

  Well actually the resolution is the same. But the current spec forces
to double entries for URI and SYSTEM, especially if you use rewriteXXX and
delegateXXX to build hierarchical resolution systems (acting like a 2 or
3 level web cache collection).

> 2. The external identifier catalog semantics are well understood and
> have been used by the SGML and XML communities for years. It was a
> requirement of the TC that the semantics of XML Catalogs in this
> regard would be exactly the same as the semantics of TR9401.
> 
> General URI lookup is a new feature so it seemed reasonable to isolate
> it.

  But you're applying the same mechanism for resolution of URIs this
is the same algorithm as with no publicid. I fail to see the real problem
there was no URI entries in TR9401, and the objects manipulated by both
URI and SYSTEM resolution are of the same type (URI-References).

  Maybe I missed something, but I can't see a clear use case where
one is forced to duplicate the full set of syntax rules to actually handle
the job of separing a given URI resolution from a SYSTEM one (unless
you want to process differently a Dtd URI depending on the context but this
seems out of the scope of simply a catalog system).
  Separating both resolution also forces from an implementation point
of view to provide separate APIs, so this forces catalogs to be more
complex, but also makes the code more complex.

  No I fail to see the justification, maybe you can expose a concrete
example, I can't understand this, sorry. My goal too is to make use of
Catalogs as simple and systematic as possible, this includes keeping
it simple for users or tools managing them.

   yours,

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/