Re: XML catalog draft

> Sorry I wasn't clear. I don't mind that there exists a non-proprietary 
> method as long as there is also the ability to create proprietary methods. 
> In fact I favour it. I think it would be good if we could agree on a 
> default standardized method.

Sorry that I misunderstood, then.  So let's define such a method.

> But don't think that the existence of PUBLIC in the grammar should be
> tied to our figuring out a resolution mechanism for them. You and I
> agree that XML documents can be interchanged without a well defined 
> public identifier resolution mechanism (using system).

Yes, we do.  But once you add PUBLIC, you have to specify how it
changes the meaning of SYSTEM identifiers -- e.g. does a PUBLIC
identifier override a SYSTEM one, and can you have bother, and what
do you do if one isn't found but the other is, and what do you do if
they are both found and are different, or should you only look for one?

Minor differences in algorithms between packages can be a major
headache.  Panorama's method has changed slightly two or three times
since the first release -- the biggest change was moving from CATALOG
to catalog -- but even the slightest change causes a major support load.
No change has been made without good reason, but some people now keep
multiple SGML OPEN CATALOGs for a single SGML file.  And that's with
only one vendor.

> You seem to believe that leaving PUBLIC in the grammar without a 
> resolution mechanism will inevitably lead to [lack of] interoperability,
> and I don't believe that.

I've seen it happen.

> I think that it will just lead to people using 
> public identifiers in prearranged systems and system identifiers on the 
> Web.

There can be no pre-arranged anything on the web unless you are
publishing only to people who have permission or something.
It all happens when it happens.

> I believe that PUBLIC is useful without a well defined resolution 
> mechanism, through pre-arranged conventions and systems, and you may 
> not believe that.
I don't.  I think it's harmful in our environment.

> Or, to put it another way: in the days before SOCAT, would it have been
> better to have no public identifier mechanism at all? I certainly used
> it before there was a well defined mechanism.
So did I.  At one point, I proposed a product called the SGML Exchanger.
It would ask you for source and target systems, and then edit your SGML,
rewriting system and public identifiers, moving DOTYPE lines into or
out of the DTD, and updating a CATALOG, extdid.map, rb.map, or whatever
file or files the application needed!  That's how bad it was.
People who used more than 3 or 4 SGML products had a nightmare.
That's why SGML OPEN catalogs were designed (thanks, Paul!!!) and that's 
one big reason why SGML had difficulty in catching on -- more than
half the time you couldn't even load someone else's SGML file into
your SGML application, depsite SGML being a standard for document
interchange -- and we can do better, and we have to do better.

> Author/Editor, in particular had/has a very powerful mapping format
> that does many things that SOCAT does not.
And which we will get rid of as soon as we can in favour of CATALOG.
Frankly, having regular expressions to match the public ids was a
disaster -- can you imagine how often a public identifier contained
a (  or ) or a + or *?  We get support calls about extid.map from
almost every A/E and R/B installation -- too much power.  These days
they mostly want to use CATALOG.

I agree that the default entry in extid.map is useful, and so is
the stuff to map system identifiers -- CATALOG could do with that.
Maybe Paul and Peter should get together and make a proposal.

But I don't want XML users on the web to have to say
Ah, they're publishing this file for Netscape 5.2, but I am using
Microsoft Internet Explorer, and I have to use the DNSMAP system,
so I can't look at this file unless I download it to my hard disk
and make a CATLOG file where Netscape expects it.  I wonder if there's
a PDF version?

It has to "just work" in the common, simple cases.  By all means go off
and do more powerful things yourself.  Imagine if you could only view
HTML files by prearrangement...

Sorry for the rant.  I think that getting this wrong or right is
probably more important than anything else, as it doesn't matter how
good a language is if you can't deploy it smoothly.

Lee

Received on Sunday, 9 February 1997 16:58:30 UTC