Peter B. West wrote: > >>These can (probably will) get out of sync. The dtd should be the one > >>used when the document was last modified, shouldn't it? It seems to me > >>there is a case for including the schema subtree, including catalog > >>file(s) and the dtd subdirectory, in the src/build tree, and maintaining > >>the synchronization locally. > > > > 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 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. 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 ...". I think the terminology is a bit confusing, probably because this stuff comes from SGML, which was created long before the net became popular. PUBLIC doesn't refer to the access of the document, but rather to the fact that the DTD is shared and therefore needs its own standard name. > That means that it is perfectly safe to keep local copies of the > documents, as long as you get the association right. If you keep a local copy of the DTD & use it for validation, you do run the risk of having the document validate on your machine, but not validate by Forrest. In practice, I hope this will not happen, but I see nothing to prevent it. To keep synchronized with Forrest, we'll have to point to their DTDs. If they change something that makes our stuff break, we'll just have to deal with it. Victor Mote --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
