Re: public identifiers [Re: Referencing multiple DTD in an XMLdocument]
"Liam R. E. Quin" wrote: > > On Wed, 3 Nov 1999, james anderson wrote: > > David Brownell wrote: > [...] > > > I'd encourage you to use PUBLIC identifiers as well, so that > > > local cached copies of those declarations can easily be used. > > > > Could someone expound further on this statement? > > I would *discourage* you from using PUBLIC identifiers. > Any system that bases caches on PUBLIC rather then SYSTEM identifiers > for XML is broken. Unless done as I later elaborated ... tho long-term caching on SYSTEM identifiers can be substantially worse. With PUBLIC ones there's the expectation (from the document provider) that there be such a caching mechanism ... and, very handy, a backup access method (SYSTEM id) is provided in case the client doesn't grok the appropriate caching. > The PUBILC keyword is there for backwards compatibility with SGML; > its meaning in XML is not formally defined, and it's usually ignored. > Therefore, if you want interoperability, simply forget it's there. That's way too extreme. One specific use for PUBLIC ids is called out in the XML spec. It's been used interoperably for almost 2 years now, just counting the context of XML. The suggestion was to use it. There's the issue I noted (namespace of PUBLIC ids isn't specified), but that can be dealt with. Normally people use IDs that are also legal SGML FPIs, and manage them like they manage FPIs. Several other schemes can work too -- it's all in how you use the identifiers. It's not that PUBLIC ids are perfect ... but there is one substantial problem that they can manage nicely, even with their current warts. And that's providing a cheap (!) way to avoid network access for external entities, notably for DTD components. It's not just folk with 28.8Kb modems that have such issues; those T1 lines also have better uses for their limited capacity, and sometimes there's no net connection at all. > [...] > > > I've yet to see a conclusive discussion of whether > > dtd's (or for that matter schema) in the namespace age are stable. That is, > > whether the same system uri will always identify an identical dtd/schema. > > They are not and it won't. Doesn't that conflict with your advice to cache based on SYSTEM ids? Clearly _some_ SYSTEM ids are stable enough to cache. The trick is how to know which those are ... hmm, that's part of why PUBLIC ids exist, they can be "known" to be stable enough (if you know what the ID means; I'd not advise automated guessing). > <!NOTATION sh SYSTEM "/bin/sh -c"> > <!ENITY systemdate SYSTEM "/bin/date" NDATA sh> > > now systemdate returns a different value every tiem you use it (maybe > evenwithin the same document, depending on the processor). > > This use of NOTATION is implied by the XML spec I never found such an implication, and I've been over the XML spec more than once with a fine tooth comb. You may be thinking about PIs, though they don't involve SYSTEM ids. ("<?sh /bin/date?>" that is.) For that matter, that's an unparsed entity, so it will never be included as (parsed) text in any XML document ... "systemdate" can only be used as a value of a "NOTATION" attribute. (Plus it may well be that "/bin/date" isn't a valid relative URI, as it must be to be used in a SYSTEM identifier.) > and by the SGML handbook, > but since a docuemnt you recieve could just as easily use "format" or "rm", > it's not a good idea, by the way. It might be implied by the SGML handbook, but I'd surely hope that in this day and age, nobody would contemplate desiging a new system (e.g. one using XML) with security holes that big. > > For example, would a processor be conforming if it were to, upon not finding a > > resource "under" a public identifier, retrieve and expand the resource located > > through the system identifier and cache the expanded (or even decoded result) > > "under" the public identifier? > > You can do whatever you like with a public identifier -- it's undefined. ... undefined except for one specific usage, which is explicitly called out (not just "implied") in the XML specification. > No amount of wishful thinking will make it otherwise, for those who > want to use it :-) sorry. Umm ... your facts are generally a _lot_ better than that! - Dave xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format