OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[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