[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: agenda for ER TC teleconference 20010507
Basically, the catalog entry types are designed to indicate what the input is, not how to treat it. The reason for SYSTEM and PUBLIC entry types is because, in XML 1.0, you may have one or the other or both, and you need to know which is which to be able to execute the algorithms that are defined to do catalog lookup. There is no reason to pervert this by looking inside a SYSTEM string and deciding it's really PUBLIC. Now that we can do delegation on SYSTEM, there is no advantage to being able to pretend that a SYSTEM id is a PUBLIC id, and certainly no advantage to pretending that an arbitrary URI is anything but a URI. At 09:55 2001 05 07 -0400, Norman Walsh wrote: >The only place that public/system entries are relevant is when the >XML 1.0 declarations are used: > > <!DOCTYPE book PUBLIC "urn:publicid:..." > "http://..."> > >In this case, the URN is a public id and the http: URI is a system id. >No problems there. > >So the only place where your suggestion that urn:publicid: is a public >identifer would arise is this: > > <!DOCTYPE book "urn:publicid:..."> ^ SYSTEM Without "SYSTEM", your declaration isn't valid. And once you put in "SYSTEM", it makes it pretty clear that treating it as a public id is wrong. >Although I still think it's a bad idea, my resistance is weakening. There >would be a certain perverse pleasure in making xsi:schemaLocation actually >contain *public identifiers*. :-) Why, there is no advantage. The Schema group has on its list of possible additions our issue, and we can also invent an OASIS xsi: sort of thing if we want (though I'm not sure I do at this point). In my view, whether something is a SYSTEM or PUBLIC id depends solely on which XML 1.0 production that string satisfies. That is the point of the different entry types. If there is a use case that we are trying to solve here, let's solve it within the realm of our catalog lookup semantics, not by pretending thata string matched a different XML production than it really did. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC