XCatalog proposal draft 0.1

[Lars Marius Garshol]

* John Cowan
>
>They come in two syntaxes:
>one which is a subset of Socat syntax, and one which is an
>XML document instance.

I have to agree with the others speakers on this:  
  - SO Catalogs should be supported for backward compatibility  
  - XCatalogs are to be preferred over SO Catalogs, since they    
    limit the number of syntaxes one has to learn

Also, implementing XML catalog support is much easier than
SO Catalog support.

I have now implemented support both for SO Catalogs and the XML
version of XCatalogs in xmlproc 0.50, which I released earlier
today. The support is still rather experimental, and does not
handle entry conflict resolution correctly.

Once support for SO Catalogs was in place XCatalogs required
just 20-30 lines. :-)

>    <Extend Href="http://www.w3.org/xcatalog/mastercat.xml"/>

A small nit:  ^ should be HRef, of course.

>4. DTD
>
>The DTD for the XML instance syntax is (where an XCatalog element
>is the root):

What is the public identifier of this DTD? 

>	<!ATTLIST XCatalog>		Version CDATA #FIXED "1.0">

Should this perhaps be 0.1?

>In the XML instance syntax, any #PCDATA content is considered comment,

Smart! Definitely a good idea!

>For uniformity below, the Map, Delegate, Extend, and Base elements 
>are referred to as "entries". 

Any particular reason why Document and Remap (SYSTEM in SO Catalogs)
have been left out? Also, what about the more controversial parts of
SO Catalogs such as ENTITY, NOTATION and DOCTYPE? I haven't made up
my own mind about these yet, but it would be nice to hear some other
opinions on this.

(Hmmmm. Section 6 seems to have been omitted. :-)

As for section 7 I find the explanation a bit cumbersome. Perhaps
the algorithm could be generalized by using a priority system between
entry types and individual entries?

Also, have you verified that this section is 100% compatible with
SO Catalogs? IMHO, it should be, so that one can implement a general
catalog engine that is independent of the syntax. If the search
algorithms do not match 100% this will be much more difficult, and
anyway I can't see any reason to have different algorithms. IMHO
the spec should also explicitly note that the search algorithms are
the same.

>If both syntaxes are supported, should Delegate and Extend entries
>be allowed to refer from one syntax to another, or should Socat
>catalogs refer only to other Socat catalogs and ditto for XML
>instance catalogs?

I think a catalog should only be allowed to refer to catalogs using
the same syntax, unless we can standardize some means of detecting
the catalog format prior to parsing the catalog. (File names, 
MIME-types etc.) If XCatalog implementations must support SO Catalogs 
IMHO XCatalogs should be allowed to refer to SO Catalogs, but not vice 
versa.

Another thing: it might be a good idea to standardize environment
variables and Java properties that can be used to point to the site 
socatalog/XCatalog, so that all parsers can use these (if they are 
present).

I'd call the environment variables SOCATALOG and XCATALOG, and the
Java properties xml.socatalog and xml.xcatalog.

Overall, great effort! Keep going!

--Lars M.



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)