Re: XML catalog draft

lee@sq.com wrote:
> 
> [this is a long article because of the notes at the end on how Panorama
>  actually fetches SGML OPEN CATALOG files, and some (by no means all)
>  of the issues involved.
>  Lee
> ]
> 
> Paul Prescod wrote:
> > The proposal leaves the resolution mechanism up to the application as it
> > should.
> 
> No it shouldn't.
> I want something that works.  In the same way.  Everywhere.
> That is what we all need.
> 
> There is no point saying the market will produce lots of competing
> mechanisms and the best one will win.   They will all lose.

I think history disagrees. 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.

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.

Now it would not have hurt anything if SGML had *suggested* a resolution 
mechanism for each of them, as long as there was an "out" that would allow 
XML to be created and to ignore posix file names and FPI catalogs (or 
whatever else SGML would have standardized).

Progress has not stopped. Things still change. I think it would be a
huge mistake to exclusively require a single mechanism that "works in 
the same way everwhere", for always. In fact, I think it would be an 
impediment to development *right now*. When I use XML on my intranet, 
I should be able to use whatever mechanism I want to find the catalog, and 
I should be able to skip the catalog altogether if I feel like it.

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

> 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 
ssyntax. As far as I was and am, concerned, the provision of that syntax is 
*sufficient* for a high quality, useful standard. 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. You can even have 
your httpd map public identifiers to system identifiers. 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.

I've made the analogy before that public identifiers are addressing processing 
instructions. Every parser must read them, but they need not use them in the 
same way. If you want 100% reliability, then you can either standardize 
explicitly (as people sometimes standardize processing instructions, within a 
department, organization, or across the whole SGML community), or you can avoid 
them (and use system identifiers) or use them internally and map to system 
identifiers externally (using httpd, or Perl or whatever).

To argue that a feature is useless if everyone cannot use it in the same way
is to argue that processing instructions or formal system identifiers or
new URL schemes or alternate text encodings or even DTDs... are useless. 
Sometimes you put hooks into a spec for *private use* and hope that enough 
people will find it useful in private to try to standardize it publically. If 
we want to standardize it publically now, we can, but we should not try to force 
our solution on everybody, because this is, in my opinion, one of the 
points in the spec that we should explicitly leave open to experimentation.

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.

 Paul Prescod

Received on Saturday, 8 February 1997 20:48:35 UTC