XCatalog proposal draft 0.1

[John Cowan]

Lars Marius Garshol scripsit:

> 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

I agree too, but didn't want to prejudice the opinions of the
XML-DEVers.
 
> 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.

I propose something one week, rough consensus emerges the next
week, and working code a week or two later: such is the Internet
freeware development community.  Peace, it's wonderful!
 
> 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.

I disclaim all efforts to set capitalization standards.  Personally,
I like all-uppercase element names and all-lowercase attribute names.

> >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?

Make one up.  I would lean towards something like
"-//XML-DEV Mailing List//DTD XCatalog 1.0//EN
 
> >       <!ATTLIST XCatalog>             Version CDATA #FIXED "1.0">
> 
> Should this perhaps be 0.1?

The *draft* number is 0.1, but the standard will be 1.0 when it is
a standard.

> >In the XML instance syntax, any #PCDATA content is considered comment,
> 
> Smart! Definitely a good idea!

Thanks.
 
> >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?

DOCUMENT is very likely not a problem, and I wouldn't object to
it too much in the draft, but it's really separate and distinct from the
idea of XCatalogs as enablers for public IDs.  (To its credit, OASIS
TR 9401:1997 admits there are two separate issues.)

As for SYSTEM: it is laid down in the XML spec that system IDs
are URIs, so remapping them here is inappropriate: URI interpreters have
their own conventions for remapping.  (It's easy to write a trivial HTTP
server that does nothing but redirect, and there are several public ones
in operation, such as http://purl.oclc.org .)

> 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.

A (validating) XML parser that respects any of these is out of compliance with
XML 1.0, so I ignore them.  Their effect (loosening the bindings
between XML objects and external objects) can be achieved by making
the corresponding declarations in the DTD or instance refer
to public IDs in some catalog.

DTDDECL does the same thing as PUBLIC in an XML context, and I thought
of supporting it for backward compatibility, but I realized that
backward compatibility is pointless, since DTDs are almost always
either XML or SGML and rarely both.  So we might just as well treat XML
DTDs just like all other external entities, using PUBLIC.

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

Yes, it used to be Example, and then I remembered that some people
like their examples up front.
 
> 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?

Feel free to come up with a better explanation.  Section 7 as written
is a direct description of the obvious algorithm, and anything
that works "as if" this algorithm were being used is certainly
going to be compliant.

> 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.

There are a few problems.  XCatalogs as specified are case-sensitive
whereas OASIS TR 9401:1997 is not, but all actual catalog examples
use uppercase only AFAIK.  Also, I have imposed a slightly more
restrictive comment syntax, requiring whitespace both before and
after all comments, except comments at BOF or EOF.  This too
seems to conform to actual practice.  (Note that the formal grammar
of TR 9401:1997 is *not* authoritative about comments: 8879 is.)

> 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.

Nor can I.

> IMHO
> the spec should also explicitly note that the search algorithms are
> the same.
 
Good idea.

> >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.

Is auto-detection really so hard?  (If it goes "plop, plop" it could be
a frog or a ripple, but the frequency of a frog is too high to
think about, as is the rest mass of a ripple.)

Anyway, what about the Master Catalog?  By your rules it would have
to be both a Socat (when it is referred to by Extend) and an instance
catalog (when it refers to other catalogs via Delegate).

> 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.

I would rather have just one variable/property, allow multiple entries
in it, (the "system-dependent list of URIs" mentioned in clause 7)
and make the catalog parser worry about syntax.  But I am not
averse to standardizing names.
 
-- 
John Cowan	http://www.ccil.org/~cowan		cowan at ccil.org
	You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
	You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
		Clear all so!  'Tis a Jute.... (Finnegans Wake 16.5)



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)