Re: ERB Decisions of March 26th
> > In my opinion, Resolution is
> > NOT
> > part of your charter. You are not going to tell me
> > what to do with a URL, that's my problem as an application.
> Luckily that's not what is meant by resolution of PUBLIC identifiers.
1. Can I repeat my earlier request for someone to post a 1-sentence
definition of what we mean by "resolution" here, please? As I see it,
a. finding out the URL which represents a given pubid
b. (a) plus going and successfully getting it.
2. Can someone confirm that in the XML context, "sysid" means "URL"
(at the moment) and _only_ "URL", not "local file name"?
> Actually I am still not convinced. People have said lofty abstract
> things about keeping name and address separate, others have said that
> a query and an address must _not_ be separarate (in a separate thread),
> some have given examples of how their existing non-web non-internet
> SGML systems need PUBLIC (but no-one is forcing them to be replaced)
> and I have not yet seen any need for PUBLIC identifiers in _XML_.
I'm still surprised this one hasn't sunk in. PUBLIC is needed in XML
because URLs (the only alternative?) risk non-persistence. I know that
home-brewed pubids also have that risk, but the structure of an FPI
is a statement of ownership of this particular item.
If I write an XML file using Mr Foo's Wonderful DTD which I found on
the Web somewhere, I can either point at it with his URL, or I can grab
a copy and point at my URL. In neither case am I _necessarily_
providing information to the end-user about where this gizzmo came from
and how it can reliably be found at some future date, when Mr Foo has
emigrated to Mars and I have retired to grow roses. Encouraging FPIs
means making authors think twice about where they put their DTDs and
how they provide for others to use them.
A formal public resolution is the only current method of doing this.
We've just seen URL-inspired resolution fail on c.t.t. yesterday:
someone posted looking for details of gmat, saying that the server
jasper.ora.com was unobtainable, which indeed it appears to be, but
gmat is still there, on ftp.ora.com . I really don't see why we
should encourage people to go down this road.
As I said last night, URNs are supposed to fix all this, but I have yet
to see proof. I have suggested a mechanism to resolve FPIs and even
implemented it -- albeit crudely -- but I still think we have too many
broken links already on this network, and I have no wish to contribute
more of tham than I already have :-)
> Personally I would favour getting rid of the special DTD line on DOCTYPE,
> and requiring inclusion. Then I would like to allow entitiy expansion
> in SYSTEM Ids, so tht I could do
> <!DOCTYPE ANKLE [
> <!Entity server % "http://www.sq.com">
> <!Entity theDTD STSTEM "%server;/sgml-docs/dtds/legs.dtd">
> That's one fewer construct in the language, fewer productions, and
> you get more powerful indirection than today, since you could load
> an external file that would define %server.
> This is more like an SGML approach to CATALOG in some ways.
Now you're talking...but pubids already do this kind of thing: they
just don't happen to do it in URL syntax.
> As far as I can see, apart from not supporting the rather odd syntax
> of FPIs, this has every feature that the PUBLICers are asking for,
Yes, I'd agree 100% if we could get rid of the flakiness of URLs and
make a positive id on who actually is responsible for each "thing"
that a pubid or sysid represents.
Believe me, if this bird flies, it is going to be crucial to know who
did what, and where you can reliably get a copy.
> <!DOCTYPE ANKLE [
> <!entity CATALOG % SYSTEM "catalog.xml">
> <!--* solves the question of how to find CATALOG *-->
> <!Entity theDTD STSTEM %lower-leg-dtd;>
> <!--* lower-leg-dtd is a "PUBLIC" identifier defined in CATALOG *-->
I like what you're doing here, but where do I find catalog.xml? Whose disk?
Who is responsible for it? And where can I get a copy in 2007?