XML Catalogs Working Draft 12 Jun 2001

[Daniel Veillard <veillard@redhat.com>]

    Hi Norm, all,

  Some feedback as I'm starting to make code:
    - 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
    - 4. Using Catalogs
      2/ prefer attribute referenced before being defined, i suggest making
      a link to the definition (same for xml:base related prose).
    - 5.1. The xcatalog File
      I really dislike this mechanism. It breaks the XML processing model
      in general, we should not add this step when loading an XML resource.
      It's hazardeous (like reusing a directory where another project was
      loaded before), and transform the relatively rigorous XML parsing
      process by adding a step allowing random failure. For me it's really
      not an option (i.e. I won't implement it).
      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
      by the author and more flexible. If there is a system wide catalog,
      then the tool knows it (/etc/xml/catalog or whatever).
    - as already pointed to Norm, the spec lacks a full example, this
      would help (a small one in 4 Using Catalogs would be nice or making
      the one in 3 a complete example)
    - "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.
    - 7.1.1. Input to the Resolver 
      what do you mean by "unwrapping the URN" ? example please !
    - 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 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.
    - 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.

  Sorry, this grew up a bit more than expected initially (it's good to
be on the other side sometimes ;-)

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