[Bug 27001] Terminology: identity

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

--- Comment #1 from Jonathan Robie <jonathan.robie@gmail.com> ---
(In reply to Jonathan Robie from comment #0)
> 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?

FWIW, I was not asking whether we could create new terminology, I was asking
whether we needed to have something analogous to "node identity" for maps and
arrays in order to distinguish copy semantics from reference semantics in a
constructor.  We rely on node identity for this in the semantics of element
constructors, attribute constructors, etc.

> 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.

I don't think this is clear about what it means by "identical to themselves" -
does that mean having the same values? Is an object still "identical to itself"
if its value changes?  What about "different from other things" - is a node N
"different from" an node O if they have exactly the same values?

In the status quo terminology, each node N has a unique node identity that
allows it to be distinguished from another node O, even if (1) N has exactly
the same values as O, or (2) the values of N change.

Applied to nodes, value comparisons and general comparisons are based on
values, not node identity. Node comparisons are based on node identity or
document order.  PULs identify changes to nodes by 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.  

Extending the term "identity" to integers leads to two different meanings of
"identity", and I find that confusing. 

I also find your definition of identity as "the property of things which makes
them identical to themselves and different from other things" confusing. I
prefer your definition (b) here:

> 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.

Our specification uses "identity" much as Grady Booch does when he says:

<quote source="Object-Oriented Analysis and Design with Applications">
An object is an entity that has state, behavior, and identity.
</quote>

The XDM does not have behavior, but it does have state and identity.

<quote source="Object-Oriented Analysis and Design with Applications">
The state of an object encompasses all of the (usually static) properties of
the object plus the current (usually dynamic) values of each of these
properties.
</quote>

<quote source="Object-Oriented Analysis and Design with Applications">
Identity is that property of an object which distinguishes it from all other
objects.
</quote>

Let's consider this with a few examples:

Example 1: Elements

$a := <i>1</i>
$b := <i>1</1>

Are $a and $b "identical"?  We don't license either question. We can ask if
they are the same node, which is equivalent to asking if they have the same
identity. They are two different nodes.  We can also ask if they have the same
value, and they do.  These two questions must be distinguished.

Example 2: Integers

$a := 1
$b := 1

Again, are $a and $b "identical"? They have the same value.  We can't really
ask if they have the same identity - that would be equivalent to asking if they
are "the same 1", as opposed to "different 1s", which is a rather odd question
to ask.

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

This does not seem clearer to me.  We are asking whether two instances of a map
or array that have the same values are distinguishable. 

Example 3: Maps

$a := { "one" : 1 }
$b := { "one" : 1 }

Do $a and $b refer to "the same map" or "different maps"?

We could decide that our data model and our language do not license the
question, as for integers - maps are just values, we can ask if they have the
same value or not.  Or we could decide that they do license the question - maps
can be distinguished from each other. If they are not distinguishable, there is
no identity to expose.

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

That does not seem clearer to me. It loses the assumption behind the example. 
Under a different assumption, the behavior would be different.

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

Both statements are true.

>   - 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).

Because a GUID is a value, this is not identity in the sense of node identity.
If the value of the GUID were to change, or two different maps were assigned
the same GUID, we would lose the ability to distinguish maps independently of
their values.

That may be perfectly acceptable, but we should not blur these distinct uses of
the term "identity".

>   - 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.

Read "lose the ability to distinguish maps or arrays independently of their
values".

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

Again, "identity" is a shorthand for the ability to distinguish maps or arrays
independently of their values.

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

Received on Wednesday, 8 October 2014 21:17:52 UTC