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

[Osamu Tatebe]

Hi Manuel and all,

Just one quick 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.

Our suggestion is this "interruption" is applicable and also useful to
other junctions such as Endpoint Reference Junction and Virtualized
Reference Junctionnot not only to Referral Junction.  In this case,
"referral message" can be extended to "junction message".  That is
why 'Type' is needed to distinguish these three junctions that cause
the "interruption".

Also, please do not forget to reflect Hiro's comments.

Thanks,
Osamu

>> On Fri, 24 Jun 2005 18:11:33 -0700, Manuel Pereira <mpereira at almaden.ibm.com> said:

>> 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