Re: Public Identifiers, and CATALOGS

A strange comparison:
> >                XML docs are portable      XML docs are for Web only
> > 
> > XML needs
> > PUBLIC, catalogs         yes                      no

Peter Murray-Rust responded:
> It's important to realise what this phrase means, and it's very restrictive.
> ***It means that these documents cannot interact with anything outside a very 
> limited environment unless rigorous protocols are put in place.***
> For example, when I receive a document(A) which references a relative URL(B)
> (e.g. "html.dtd"), then the identity of B depends on the context(A).  If the
> only operation is transfer of documents between the client and the server
> then the integrity is maintained.  If, however, I want to *save the documents
> to local filestore* the integrity is lost.

This happens today with HTML documents, and is the reason why the world
wide web never became populer.  Er, oops.

If you save an HTML document, all relative links will immediately break.
This often means that you lose included images, for example, as well as
links to other pages.

* change links to make them absolute (complete) instead of relative
* save multiple files so that all immediate relative links work, and
  possibly edit relative links in other text files that are saved
* do none of the above (e.g. it's your own file & you're going to edit it
  here and thenput it back on the server)

But neither MSIE nor Netsape nor yet Mosaic does that for HTML files today.

> Of course with careful client-side maintenance this restriction can be 
> relaxed, but the likelihood of inexpert users breaking the integrity is
> considerable.  A (?the) primary role of PUBLIC is thus to act as an integrity
> check at the client side, even if it's not used for resolution.

I don't agree here.  Non-expert web users survive just fine with exactly
this problem.  Yes, links break.  No, catalog won't generally help, because
chances are that the way in which a link breaks means you can find neither
the SGML file nor the CATALOG file!

Yes, people doing large-scale complex SGML-style work with XML will feel
constricted.  No, I don't care.  Sun is using SGML and not XML for their
documentation.  Perhaps XML will evolve into something that has enough
features to satisfy everyone one day.  I'd rather drive a Morris Minor --
er, a VW Beetle/VW Bug or a CV2 -- today than wait for a solar-powered
cadillac.  Well, actually I don't own a car, as I don't need one in
Toronto.  There's enough public transport infrastructure that it's
simpler not to drive, and you rarely wait more than ten minutes.  Like
the web, it's not perfect, but it's good enough.

It's interesting that Steve (I think?) contrasted "for the web" and
"portable".  I'd say that the average moderately well-formed HTML file is
far more portable in practice today between applications than the average
SGML file.  If you don't believe me, open SGML documents in 30 applications
and show me how they look similar, without compiling rules or editing
configuration files.

Yes, there are people using SGML today who are happy to edit CATALOG and
do other manual tasks in order to view or edit an SGML file.

But it doesn't have to be that way, and we have the power to change it.

I'm with Peter Murray-Rust on his a-h taxonomy (in another message).
I think that automatic interchange is very important.  XML will be used
on the web, and that is our primary focus (see the Activity page) and
it will be used in many other places.  But if it doesn't work well on
the web, because we didn't get interchange and interoperability right,
I don't thinkwe can say we have succeeded in our allotted task.


Liam Quin, lee@sq.com         | lq-text freely available Unix text retrieval
Senior Technical Consultant   | FAQs: Metafont fonts, OPEN LOOK UI, OpenWindows
SoftQuad Inc. +1 416 544-9000 | xfonttool (Unix xfontsel in XView)
http://www.softquad.com/      | the barefoot programmer