Re: XML Catalogs Working Draft 12 Jun 2001

[Daniel Veillard <veillard@redhat.com>]

On Wed, Jun 20, 2001 at 08:27:03AM -0400, Norman Walsh wrote:
> / Daniel Veillard <veillard@redhat.com> was heard to say:
> |     - could you specify whether attributes can be anchored in the
> |       namespace (e.g. <cat:catalog cat:prefer="system" cat:id="top"
> | 	   xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog"> is
> | 	   allowed or forbidden) ?
> |       I suggest to make it explicit
> 
> I believe our intent was that attributes would be in the element
> partition, not global:
> 
>    <cat:catalog prefer="system" id="top"
>                 xmlns:cat="urn:oasis:names:tc:entity:xmlns:xml:catalog">
> 
> I think it should be an error to use them in the global partition.

  okay, maybe worth a sentence in the spec.

> |     - 5.1. The xcatalog File
> |       I really dislike this mechanism. It breaks the XML processing model
> 
> I'm not a huge fan either.
> 
> |       If the author wants to signal the presence of a catalog use a
> |       PI (like the xml-stylesheet one) at least it's clearly flagged
> 
> We originally had a PI for this, but that has its own set of problems.
> Specifically, you have to have started parsing before you see it, so
> if you need it to find the doctype, you're hosed.

  Well the PI would have to be placed before the DOCTYPE, and rule to
ignore it if it is located after sounds a simple way to avoid the tortuous
case where there is one after the DOCTYPE.

> |     - "The nextCatalog element" ... this is used multiple time along the
> |       spec and leads to the idea that only one nextCatalog is allowed while
> |       global catalogs would definitely need the possibility of a tree
> |       of catalogs, I hope it's possible.
> 
> Yes, you can have as many as you like, I'll make that clearer.

  okay, thanks :-)

> |     - 7.1.1. Input to the Resolver 
> |       what do you mean by "unwrapping the URN" ? example please !
> 
> Ok. Look at the Internet Draft, too, that may help.

  Sorry, will do !

> |     - the spec in general would benefits from a set of "definitions"
> |       and links to it from the usages. Example
> |       resolution, delegation, URI reference, external identifier,
> |       base URI
> 
> I'll see what I can do.
> 
> |     - I haven't checked yet but I hope the algorithms in 7.1.2 and 7.2.2
> |       can be implemented without too much troubles with a single hash table
> |       for all entries based on a set of fully loaded catalog tree. I hope
> |       steps 6 and 7 won't force a too complex implementation.
> 
> It absolutely cannot be implemented with a hash table. I think you
> really have to build a linear structure and walk over it (sometimes
> more than once).

Seems that linear for clashes in the hash based on a subscring may work,
I need to think more, the rewrite mechanism imposes a new set of constraints.

> |     - 8 don't specify very clearly hoe to define that a given resource
> |       is a catalog. Is the check 
> |         - it's XML
> | 	and
> | 	- there is a root node
> | 	  - its name is catalog
> | 	  - its namespace name is "urn:oasis:names:tc:entity:xmlns:xml:catalog"
> |       the one the applications should implements ?
> |       Anyway this should be precised.
> 
> I think that's the algorithm.

  Okay good, I think I have the informations needed,

    thanks for the timely answer,

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/
Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com