Victor Mote wrote:

It seems to me, on reflection, that I had this completely wrong.  They
can't get out of sync *while they have a PUBLIC identifier.*  I am still
naive about such things, but doesn't the assignment of a PUBLIC ID
ammount to a contract that the document so named will never change?  If
you want to change it, you must assign another PUBLIC id, because people
all over the net are relying on the constancy of the association between
the original PUBLIC id and the actual document.

I don't know that there is any "contract" per se.
I think the contract does exist, at least IMO the essence of Public Id is to be globally *unique* name of an entity [1]. Excactly one didtinct entity, usually specific version of a dtd.

I would think of it more
as a naming convention, a reserved /name/. You & I could have the same XML
document on our local machines, and have catalogs pointing to local DTDs
that were radically different.
That's violation of the contract as Public Id should uniquely name the resource. e.g. -//OASIS//DTD DocBook XML V4.1.2//EN now and forever refers to the XML version of DocBook V4.1.2.

To my knowledge, there is no universal way to
translate a PUBLIC id into a real file (either local or on the net). Without
that, there is no file, and therefore no assurance of anything resembling
synchronization. In other words, to use PUBLIC ids, it seems to me that you
have to have some totally external convention for making the actual DTD file
available to the user of the DTD, and some external way of updating them as
well. (By "external", I mean outside of XML -- for example, somebody has to
send an email that says "the actual file is at ...".
That's why Public Id'd must be globally unique, e.g. when a dtd is modified its Public Id must be changed and this way all are notified automatically.

Oleg Tkachenko
eXperanto team
Multiconn Technologies, Israel

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to