Re: XML catalog draft

> I think that it would be better to specify that URNs be used (which I
> would support) than FPIs (which I do not support), as there is still no
> resolution mechanism that will scale up to millions of FPIs even
> proposed, let alone working, as far as I can see.  ISO can mandate the
> use of things that don't exist and might never work, but that doesn't
> mean we can, and if you need a W3C Recommendation and/or an RFC, that
> won't cut any ice.  (why do people need to cut ice?  it comes in cubes)

The proposal leaves the resolution mechanism up to the application as it
should. Therefore we do not need to argue FPIs vs. URNs. Furthermore,
when URN resolution mechanisms become available, FPI resolution
mechanisms will also become available (global resolution mechanisms, I mean),
because the representation of an FPI as a URN and the set of all FPIs as
a URN namespace is straightforward. There is no dichtomy, nor any 
competition between them.

> >  Either way, some means of associating
> > catalogues or ilinksets with documents is required.  
> Clearly -- otherwise we haven't solved the problem, but only made it
> more complicated.  A way of getting from instance to catalog is needed.

I don't agree here. Catalogs are useful without a transmission mechanism.
If I send you a file with <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
I have a feeling that your software will resolve it correctly.

On the other hand! I think that a mechanism for associating catalogs with 
instances is useful, and important. I raised this in the catalog group, and
we agreed that it was outside of our mandate and did not bother to discuss it
further.  Some of us felt that it was something that the ERB should
add when they integrate the catalog proposal with the XML spec.

I planned to recommend a mechanism to the ERB independent from the catalog
group, but could not decide between the Socat-way, with a file named
"catalog" which is very convenient, but tromps on the user's filename
space, (perhaps less if the file was named xml-cat) or with a processing
instruction, which is syntactically ugly and a little inconvenient to
add to each document.

Comments welcome.

> I will say right now that we spent a lot of effort on this topic for
> SoftQuad Panorama, and didn't get it right in the 1st release.
> 
> It's still not perfect, but we have backward compatibility issues.
> Let's do it right for XML.

What is "right"? Your experience with this issue will be useful to us.

 Paul Prescod

Received on Friday, 7 February 1997 14:21:52 UTC