|
The complex type
ContextType has child elements. It is the values of these children that I am
referring to (not to the child-parent antinomy which is another matter
altogether). So, I should have said “to the ContextType’s child elements” or
some such.
Ah, I
understand.
My reference to
getContents was intended to clearly state, that the values held by context
service at point of reception of getContents are the “current” values (i.e. to
define the meaning of “current”). I think it would be useful to retain
this.
Agreed.
It was my misinterpretation of your "reference" to child that caused
confusion.
On the matter of
dereferencing further: the decision of the F2F was to state that a getContents
got the contents. If the getter wishes to pursue a parent reference (if
present) then it needs to do another getContents, and can (obviously) pursue
the whole linked list if interested, in a similar iterative
manner.
Yes, that's what I
thought, but given the interpretation of child above it didn't make
sense.
Strictly, my last
sentence need not be stated in any way in the specification, because it
follows from the definition of the meaning of getContents, which is
effectively what your text is setting out to be. It is a logical deduction, a
behaviour that cannot be prevented other than by arbitrary restriction or
over-regulation. However, it might be useful to explain the point for didactic
reasons.
Agreed.
Mark.
Alastair
-----Original
Message-----
From: Mark
Little [mailto:mark.little@arjuna.com]
Sent: 10 August
2004 11:16
To: Green, Alastair J.;
ws-caf
Subject: Re: [ws-caf]
propsed text for issue 133
My mistake: I do have issues with
Alastair's proposed text changes, specifically the last
insert:
"i.e. the values corresponding to
the context’s child elements held by the context service at the point of
receiving the getContents message."
First, there aren't any child
elements (we changed that to a single parent-context
ContextType).
So my proposal would be to modify
the 133 text to change child to parent and drop the last bit about
dereferencing that via getContents. That would text solely related to issue
133. Then when we come to 137 and 141, which are dependant on 133, we may make
subsequent updates.
----- Original Message -----
Sent:
Monday, August 09,
2004 11:32
AM
Subject: RE:
[ws-caf] propsed text for issue 133
I
would suggest amending this to read
"If a context is present on a
received message and it [delete: that] contains a context-manager
element then that element MAY be used by the recipient to dereference the
context. Any other information present in the received context at this point
[insert:] cannot be assumed to represent the current or entire contents of
the context [delete: SHOULD NOT be assumed to represent the entire context
structure]. If the context-manager is dereferenced, it MUST return the
entire [insert] current contents of the context, [insert:] i.e. the values
corresponding to the context’s child elements held by the context service at
the point of receiving the getContents
message."
Alastair
-----Original
Message-----
From: Mark
Little [mailto:mark.little@arjuna.com]
Sent: 09 August
2004 11:04
To: ws-caf
Subject: [ws-caf] propsed text for
issue 133
"If a context is present on a
received message and it that contains a context-manager element
then that element MAY be used by the recipient to dereference the context.
Any other information present in the received context at this point SHOULD
NOT be assumed to represent the entire context structure. If the
context-manager is dereferenced, it MUST return the entire contents of the
context."
----
Mark Little,
Chief
Architect, Transactions,
Arjuna Technologies Ltd.
www.arjuna.com
|