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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrf] Resolution text for Issue wsrf 25



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
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]