Re: XML catalog draft

Paul Prescod wrote:
> [...]  SGML didn't choose a single resolution mechanism
> for either public or system identifiers. Because of the first choice, we can
> still reasonably discuss how to use URN resolvers as Public Identifier 
> resolvers without going back and changing the SGML spec. Leaving that as a 
> system option was a Good Idea and we are benefitting from it now.

We are working on XML because how to use SGML over the Web is neither
simple nor well defined.

> Similarly, SGML did not specify a special syntax for system identifiers or
> a resolution mechanism for them. Thanks to that "omission" we can now use URLs
> in XML. Once again, that was a Good Decision.
That "omission" has been corrected, and SGML now has FSIs, because of
problems with SGML systems not being sufficiently interoperable in practice.

> Suggesting a resolution mechanism would be fine, even a good idea,
> in my opinion. Exclusively mandating one would be a big mistake.

I think that again we are at cross-purposes.  I am not proposing mandating
a single resolution mechanism.  I am saying tht the proposal has to work,
in the sense that its proponents have to show how you can deliver XML
on the web (our Purpose) using it.

>> I don't care if non-Internet uses of XML don't have to include any way
>> of doing http (for example) -- I do care if two http-based XML systems
>> can't share the same files because they have incompatible rules for looking
>> up FPIs and mapping to SYSTEM IDs.
> 
> At this point, it is worth bringing in some history. XML 1.0 November Draft
> not only did not have a specification for catalogs, it explicitly prohibitted 
> public identifier lookup by not allowing any place for public identifiers
> in the syntax.

As you know, I am aware of that.  I poopsed the introduction of FPIs then,
and I still think they are making things far more complex than they need
to be or ought to be.  But if we have to have them, they had better work.

> If vendors implement public identifiers in incompatible ways,
> then you can always use system identifiers
> on the Web, and public identifiers on your internal systems.

We are not here to standardise what people do on their own internal
systems -- we are here to standardise interchange.

> If the web market demands public identifiers, they can go through the
> same process the SGML community did, to standardize them: *as long as
> the XML syntax allows it*. Which it didn't before. That is really all
> I wanted fixed.

It would be better to extend the syntax later, in XML 2, if that were true.

> To sum up: I think it would be nice and useful if we could send
> catalogs over the web in a reliable way, as Panorama does. But I
> think it is crucial that I be allowed to use them on my computer, or
> in my organization in the way I want to, without violating the XML
> specification.

What you do on your own computer is up to you.  It is only the
interchange that we must standardise.

If we have PUBLIC identifiers in files, and catalogs in some standard
way, but no way to interchange catalogs, and no way to get a catalog
given an XML file, we have failed to specify enough details to get
interchange of XML files working over the web.  And that's what we're
here for, so that's what we have to do.

If you want, you can allow for RCDATA marked sections and starttag
entities in your XML spec, in case we want them later (we might), but
I don't think that's very sensible.

Yes, there's a legacy problem, you can say -- if I can have a PUBLIC
identifier in an XML file that is ignored by all standard conforming
applications, then I can have my own private non-XML system using
them and that gives me a nice feeling.  (is that a fair summary?)
But when XML 2 comes along (say) and PUBLIC identifiers are now
required to be sock weaving patterns, you're still hosed.  And if
someone else's implementation tries to look up PUBLIC IDs before
SYSTEM IDs, and produces an error message on failure, your files are
not interoperable.  By not specifying how PUBLIC IDs work, that's
the sort of problem we'll have.

Paul, I'm sorry -- it's clear that you are trying to achieve something
that I do not understand, and in which I at present see no merit at
all, but only many problems.  Perhaps you should give us some clear,
concrete examples of how PUBLIC helps interchange XML documents
over the web, or how there is no circumstance, now or future, in
which it can hinder such interchange, and what other gain is made.

Lee

Received on Saturday, 8 February 1997 21:36:44 UTC