[gfs-wg] Re: Proposed Final Draft for RNS v1.0

[Hiro Kishimoto]

Hi Manuel,

Revised draft still have a reference to inappropriate version of
WS-addressing. I strongly recommend to update RNS spec to refer
to the latest W3C spec.

> RNS v1.0 now depends on WS-Address W3C Member Submission dated 
> 10 August 2004. Although member submission is available on W3C
> site, it is not at all standards specification.
> 
> I see several reasons RNS v1.0 should refer to the latest 
> WS-addressing specification.
> 
> - Member submission depends on several (so-called) proprietary
>   specifications, e.g. WS-Policy.
> - WS-address WG has made great job and modified their spec quite 
>   a bit.
> - Necessary changes of RNS v1.0 is immaterial and simple alterations.

You also need to change WSRF 1.1 and WSN 1.2 to WSRF 1.2 and WSN 1.3
respectively.

Thanks,
----
Hiro Kishimoto

Manuel Pereira wrote:
> Hi Osamu and all,
> 
> Please refer to the latest revision of the RNS Specification draft, now on 
> GridForge:
> https://forge.gridforum.org/projects/gfs-wg/document/RNS-Proposed_Final_Draft-v1.4/en/5
> 
> ------
> 
>>* Update operation
>>
>>'Type' needs to be described *not to be updated*.
> 
> 
> Is this a necessary constraint?  Can you please explain why this is a 
> requirement.  What if a user wanted to change an ?Alias? to a ?Referral?, 
> provided that the other corresponding properties were change concurrently?
> 
> 
>>* Symlink behavior for VFDS
>>
>>We need to consider how to implement (or represent) a symbolic link
>>(aka PathAlias in VFDS) in RNS.  Possible solution is
>>
>>1) to represent as 'Alias' but its targetPath is not updated when
>>   moving the target entry, or
>>
>>2) to represent as 'Referral' but it has 'TargetPath' instead of
>>   'EPR'.
>>
>>Unfortunately, either solution affects the RNS specification...
> 
> 
> This can easily be accomplished with the use of an extended property 
> assigned to the Entry properties document.  This extended property would 
> be defined in the GFS profile and would describe the syntax, conditions, 
> and behavior of such a property. 
> 
> An example might look something like:
> PathAlias
> -Property name: PathAliasTarget
> -Data type: String
> -Profile: GFS
> 
> This property would extend the specified Entry properties document, and so 
> an example entry record might look like this:
> [ENTRY]
>       AliasCount = 0
>       ChildCount = 0
>      Description = ?This is a path-based symlink?
> ModificationTime = 2005-06-22 14:23:00
>             Name = ?latest-build?
>             Type = Junction
>  PathAliasTarget = ?/ggf.org/data/gfs-wg/bin/build-1234?
> 
> 
> 
>>* IteratorContext
>>
>>When IteratorContext is created as ResourceProperties in WS-Resource,
>>an EPR can specify the IteratorContext (as a WS-Resource).  This
>>means iteratorContextID is not necessary, does not it?
> 
> 
> The specification requires that a service implementation be capable of 
> constructing point-in-time unique iteratorContextID, see section 1.3.4.3. 
> The EPR does specify the IteratorContext, however, to construct the 
> context that the EPR corresponds to, some unique value must be used to 
> distinguish the resource.  The createIteratorContext operation simply 
> allows the implementer/user to specify the identity of this temporal 
> resource.
>  
> 
>>* Junction message
>>
>>In the current document, a referral message is only used for a
>>referral junction.  On the other hand, this mechanism is quite useful
>>for other junctions; Endpoint Reference Junction and Virtualized
>>Reference Junction.  To do this, just add 'Type' and
>>'LogicelReferences' to QueryResponse and ChangeResponse.  'Type' needs
>>to be added to distinguish a type of junctions (or type of junction
>>messages).  In this case, 'baseDirectory' does not always refer to a
>>'directory'.  Maybe it is better to be renamed to 'basePath'.  Also,
>>'referralEPR' should be just 'EPRs' since it can refer to 'EPRs' in
>>Endpoint Reference Junction.
> 
> 
> I am afraid I don?t understand your suggestion, or I have not explained 
> the referral message well enough.  The QueryResponse is designed to 
> provide a valid answer to any query operation, provided that the operation 
> was successful.  This means that the message ?mechanism? is used for all 
> types, see section 1.3.1.3.  The ?array of unrestricted message elements? 
> is the allocated message element for Endpoint Reference Junctions, 
> Virtualized Reference Junctions, etc.
> 
> We do not want to add ?Type? to the QueryResponse, since this is a 
> property that is selectable by the caller to be included in the response.
> 
> Remember that the referral message is a special case message that 
> signifies an ?interruption? to the operation.  Its sole purpose is to 
> redirect the caller to another RNS service that will resolve the request 
> (this information is stored only in Referral entries).  You can view the 
> referralEPR message element as part of the message header for the 
> QueryResponse message.  The content of the QueryResponse is not contained 
> in the header.
>  
> 
>>Moreover, 'remainingPath' (I am not sure this name is good or not) is
>>useful that represent a path to be traversed.  Of course, this can be
>>obtained by 'Path' and 'basePath', while it is useful.
> 
> 
> Again, I am not quite sure what you are suggesting here.  If this is still 
> applicable in light of the above comment, please let me know.
> 
> 
>>* XML Structure of EPRs and LogicalReferences
>>
>>EPRs and LogicalReferences are basically a list of EPR and
>>LogicalReference, while the structure is not known in the document.
>>This needs to be clarified.
> 
> 
> I have expanded on this a bit in section 1.2.2.2.1.  Additionally, I have 
> just updated section 1.3.1.3 to illustrate an example QueryResonse that 
> now contains the XML structure of EPRs.
> 
> 
>>* <Entry> and <Target> in example of QueryResponse
>>
>>Neither <Entry> nor <Target> is introduced in the document.
> 
> 
> Target is introduced in section 1.2.2.2.1.  Although Entry is discussed at 
> some length, the QName was not introduced; I have added a brief note about 
> it in section 1.1.
> 
> 
>>* rename operation
>>
>>Now 'update' does not have 'Name'.  Need to update the description.
> 
> 
> Done, thanks for catching that!
> 
> 
>>* QueryInput in list operation
>>
>>'EPR' and 'LogicalReference' seem to be missing QueryInput of list
>>operation.
> 
> 
> Only the plural form seem appropriate as input parameters.  In other words 
> ?EPR? carries a singular connotation, whereas ?EPRs? indicates all/any 
> EPRs that are registered.  The list operation input parameters are used to 
> identify which properties should be included in the response message, so 
> it doesn?t appear to be appropriate to request only a single EPR in the 
> response message.
> 
> 
>>* Error message
>>
>>Error message (string) is better to be added in QueryResponse and
>>ChangeResponse.  Moreover, several typical error messages need to be
>>defined such as 'no such junction or virtual directory', 'not a
>>virtual directory', 'junction exists', 'is a virtual directory',
>>'virtual directory not empty', 'invalid argument', ....
> 
> 
> I agree that error messages need to be defined, however I believe that 
> adding an ?error message? element in the response message structure is not 
> the optimal approach.  Although error messages still need to be defined, 
> the current doc does specify that a (SOAP) ?fault? will be thrown (in 
> other words, a ?fault message? will be returned to the caller based on 
> WS-BaseFaults) in case of an ?error?.
> 
> 
>>* EPRs and LogicalReferences
>>
>>How to update and delete entries in EPRs and LogicalReferences is not
>>well-defined.  For example, how to create a junction entry that has
>>two EPRs?  How to insert an EPR3 to a junction entry that already has
>>EPR1 and EPR2?  How to delete just EPR2 from a junction entry that has
>>EPR1 and EPR2?  Would you describe a procedure with an example of
>>setResourceProperties?
> 
> 
> I do believe that the create case is covered in section 1.3.2.1.  It does 
> contain a brief note below the parameter table that indicates multiple 
> <EPR> elements may be used.  I have added a quick example however.
> 
> As for the update case, you are correct in saying that it was not 
> well-defined.  I have tried to enhance that section (1.3.2.5); it now 
> includes an example and much more description.  Additionally, it 
> identifies what change type messages are allowable for what properties. 
> Thanks again for bringing this to my attention.
>  
> 
>>* In the case that the specified 'Path' is a junction
>>
>>When the specified 'Path' is a junction, 'lookup', 'delete', and
>>'update' operations are for the specified junction itself, while
>>'list' and 'create' are not since these operations basically apply to
>>a sub entry (or entries) in the specified 'Path'.  This needs to be
>>clarified in the document.  In the list and create cases, a referral
>>message (or a above-mentioned junction message) could be returned as a
>>QueryResponse and ChangeResponse, respectively.
> 
> 
> The list operation only accepts a virtual directory as an input, if not a 
> fault should be thrown.  As for the create operation, it behaves just as 
> the other operations (lookup, delete, and update).  You can specify an 
> absolute path that denotes the junction to create.  The document does make 
> an explicit statement regarding the list operation only taking a virtual 
> directory, see the last paragraph of the summary section of 1.3.2.3.
>  
> 
>>* In the case that the specified 'Path' in create operation is an
>>  alias to a virtual directory
>>
>>When the specified 'Path' in create operation is an alias to a virtual
>>directory, how does the create operate?  Since 'Alias' can be resolved
>>within the service, it is reasonable to create a new entry under a
>>virtual directory pointed to the alias specified by 'Path'.  This
>>seems to be a special case enough to be described.
> 
> 
> This is a very good point.  In fact this augments the previous statement 
> somewhat in that an Alias that points to a VirtualDirectory is also 
> legitimate as input to the list operation.  I will add a brief description 
> of this consideration of Aliases.
> 
> ------
> 
> Thank you for your detailed review.
> 
> See you at GGF14!
> 
> Best regards,
> Manuel Pereira
> IBM Almaden Research Center
> 1-408-927-1935  [T/L 457]
> mpereira at us.ibm.com