Hi Tim:
>
> Steve,
>
> Some comments on the resolution of issue 25.
>
> I see no schema describing the <ResourcePropertyChangeFailure>
element
> in
> http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/11504/wsrf-WS-
> ResourceProperties-1.2-draft-06.xsd
Indeed an oversight we should log as an issue and
correct.
> There is no schema to say where in a fault this element
should go.
Right, this element can appear anywhere in the fault.
> The text says 'The fault message MUST also indicate whether
the effects
> of processing previous components were restored or not.
Any fault MAY
> contain a descendant element, named ResourcePropertyChangeFailure,
that
> indicates the resource property element associated with
the fault and
> indicates if the resource property document was restored.'
To me, this
> leaves open the possibility of using another way of describing
what has
> happened, which is too permissive.
I don't follow your point.
> I suggest: 'If multiple updates were
> present in the request, any fault MUST contain a descendant
element...'.
Essentially this is suggesting changing the MAY contain
to a MUST contain?
> I find it rather odd to have an element which describes
the effect on
> parts 1 to n-1 of the multi-part set, but
which contains details about
> part n. It can be read as if the 'restoration'
describes the effect on
> part n alone.
doesn't the text clearly state (emphasis added):
If the value of this optional attribute is
“true”, then the resource
property document was restored to
its state prior to the attempt to process the request message.
> The explanation of @Restored should say
'If the value of
> the attribute is "true" then the values of
all resource properties
> processed during the operation are restored to their
original values'.
Is it possible to restore the RP doc to its state
prior to processing the request
without restoring the values of all the resource properties?
> I propose the attribute be called 'DocumentRestored'.
Syntax.
>Even better would
> be to have two elements: one describing the restoration,
another
> describing the update that caused the fault.
The advantages of two elements would be...?
> An example would be a good way to illustrate all this.
+1
> The 'Restored' attribute is optional with a default of
'false'.
> Wouldn't it be simpler to make it compulsory?
Simpler? not sure. If it is optional,
then there is less markup and
the semantics are the same (absence == false).
>
>
> Regards, Tim Banks
> IBM TP Architecture & Technology. Hursley, UK.
> Phone: External +44 1962 815639, Internal 245639
>
