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

[Manuel Pereira]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20050624/c81f8bcd/attachment.html