[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: New draft: 13-Mar-2001
At 15:24 2001 03 19 +0000, Tony Coates wrote: >>[1] http://www.oasis-open.org/committees/entity/spec-2001-03-13.html >Also, if our two modes are "prefer system identifier" and "prefer public >identifier", then having these selected by the "override" being "yes" or "no" is >just going to be confusing (i.e. "was that 'yes' for prefer system, or 'no' ... >I can't remember now ..."). It would be much easier to understand the document >as it stands now if there was a "prefer" attribute with values "public" or >"system". Can we discuss this at today's meeting? I might be willing to consider this, but I do remember spending lots of time on this issue when we first wrote this up, and it isn't as simple as you might think. The point is that, in XML, you've got a system id that is telling you were the resource is. Now you've got some public and delegate entries in your catalog, and the question--for any public or delegate entry--is whether that entry is allowed to be used for the purpose enabling the given public id to override the given system id for the sake of finding the resource. Hence the first line of the explanatory paragraph in our spec: The override attribute can be used on catalog and group entry types to indicate for any set of catalog entries whether they should be able to be used in matches that may override an explicit system identifier. The (second) use of the word override above seems natural--I'm not sure how I'd reword the sentence if we changed things to prefer=system|public. Within the scope of override=no, public and delegate-public entry types are effectively ignored if a system identifier has been given (which, in the case of XML, will always be the case except for notations). Does "prefer='system'" convey that semantic equally well? I certain appreciate the fact that override=yes|no might leave some users uncertain as to which means which. I suppose the most meaningful name is "allow-public-id-match-to-override-explicit- system-id" (apimtoesi?--not much worse that sosofo), but that doesn't seem workable. I guess I could go either way, as long as the description of things is clear. I'm interested to hear what the editor of the spec thinks. paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC