[Bug 26958] On not precluding updates in XQuery 3.0

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26958

C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmsmcq@blackmesatech.com

--- Comment #8 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> ---
I am generally sympathetic to Michael Kay's request that we conduct our
discussion in terms of data independence and not by splitting hairs over the
meaning of terms.  I apologize, therefore, for commenting solely on the
question of terminology and not on the questions of design.  My excuse is that
I can't contribute to any design discussion if I cannot understand what people
are saying, and the use of the unqualified term "identity" to mean solely
"persistent identity across mutation or update" (instead of what I understand
"identity" to mean) makes it very hard for me to follow some of the discussion
here.  Also, since I seem to be responsible for making JR self-conscious about
his usage of the term, I would like to try to show that a less misleading usage
is possible.

JR asks, in the initial description of the issue:

    I do not believe that the value of $z should be changed, so 
    I think that we should use copy semantics here.  Is there a 
    good way to say this without referring to identity?

Yes, there are plenty of ways to say it without any use of the term "identity".
 There are also plenty of ways to say it that use the term "identity" in its
conventional English sense, without any notion that "identity" applies only to
complex mutable objects and does not apply to (say) the integers.  

By "identity" I believe normal English usage means either (a) similarity among
distinct objects (as in "identical twins") or (b) the property of being itself
and being distinct from other things.  We really do not want sense (a) here or
elsewhere.  In sense (b), every thing which we can identify necessarily has
"identity"; saying that maps, arrays, and elements have identity, therefore, is
true but not particularly helpful, since it doesn't help distinguish them from
other constructs in our data model or our languages.  What is at issue here, I
think, is that we envisage having operators whose results depend only on the
identity of the maps, arrays, or elements to which the operators are applied,
or (roughly the same thing in different words) we envisage having operators
which expose the identity of maps and arrays in much the same way that 'is' and
'<<' and '>>' expose the identity of nodes.

To test my claim that we can express what we need to express without using the
term "identity" in the ways I continue to object to, let me suggest wordings
for some sentences which, I believe, accurately convey the intended meaning.

  - For "Suppose we ultimately decide that maps and arrays have identity," read
"Suppose we ultimately decide to expose the identity of maps and arrays".

  - For "(in pseudocode, assuming maps and arrays do have identity)" read "(in
pseudocode)".  

  - For "Elements do have identity" read "Elements have node identity".

  - For "creating a GUID to represent the identity of a map" read "creating a
GUID to represent the identity of a map" (i.e. no change is needed).

  - For "to change the semantics of our languages in ways that lose identity",
I do not know what to write, because I'm not sure what's being said.

  - For "This implies identity" read, perhaps, "This implies some sort of
identity across updates".

None of the references to object identity, preserving identity, exposing
identity, maintaining identity, or changing the identity of nodes needs
revision, because all of them make perfect sense when "identity" is understand
as the property of things which makes them identical to themselves and
different from other things.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 7 October 2014 18:23:43 UTC