Lists Home |
Date Index |
- From: Lars Marius Garshol <firstname.lastname@example.org>
- To: email@example.com
- Date: Mon, 20 Jul 1998 14:45:46 +0200
* 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.
>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
>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
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
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
I'd call the environment variables SOCATALOG and XCATALOG, and the
Java properties xml.socatalog and xml.xcatalog.
Overall, great effort! Keep going!
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)