1.0rc1 WSDL issues (create node params)

Tue Jun 20 00:31:30 PDT 2006

On Tue, 20 Jun 2006, Paul Harrison wrote:

> Cannot the functionality be simply overloaded on createNode?

The idea was to avoid overloading operation names. There's a rumor that
overloading doesn't work consistently with doc/literal/wrapped.
>
> On 16.06.2006, at 16:39, Guy Rixon wrote:
>
> > CreateUniqueNode is fine by me.
> >
> > On Fri, 16 Jun 2006, Dave Morris wrote:
> >
> >> How about calling it CreateUniqueNode ?
> >> Takes optional set of properties and returns a new DataNode with a
> >> unique name within the space.
> >>
> >> We can add a type parameter in VoSpace-2.x to allow this to create
> >> other
> >> types of node, including containers.
> >>
> >> Dave
> >>
> >> Guy Rixon wrote:
> >>
> >>> Yes to introducing CreateTempNode as you have written it with
> >>> these caveats:
> >>>
> >>> 1. Is createTempNode the best name?
> >>>
> >>> 2. Spec needs language making it clear that the node is created
> >>> with a
> >>> guaranteed-unique name.
> >>>
> >>> 3. Any other special semantics that we need to write down?
> >>>
> >>> 4. Is it a special type of node? (I suggest it can't be, since we
> >>> only really
> >>> have data nodes at this stage.)
> >>>
> >>> 5. The name parameter on the basic createNode will become
> >>> mandatory if we make
> >>> this change.
> >>>
> >>> Given that the node is an ordinary data-node and doesn't have any
> >>> temporary-file semantics (c.f. the POSIX temporary files that
> >>> disappear when
> >>> the creating process exists), I suggest that createAndNameNode is
> >>> a better
> >>> name than createTempNode.
> >>>
> >>> (BTW, when we extend this to VOSpace 2, I hope we'll allow
> >>> creation of
> >>> auto-named container-nodes as well. But let's not get side-
> >>> tracked by that
> >>> now.)
> >>>
> >>> Cheers,
> >>> Guy
> >>>
> >>> On Thu, 15 Jun 2006, Matthew Graham wrote:
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> I accept Dave's suggestions.
> >>>>
> >>>> I also accept Guy's suggestion for a separate operation for
> >>>> creating a
> >>>> temporary node with a server-generated name and propose adding
> >>>> this text
> >>>> to the spec:
> >>>>
> >>>> createTempNode
> >>>>
> >>>> Creates a temporary node in a space. This method is used to
> >>>> create a
> >>>> temporary data node.
> >>>>
> >>>> Parameters: None
> >>>>
> >>>> Returns: A <node> element for the new node.
> >>>>
> >>>> Faults:  The service may throw an OperationNotSupported
> >>>> exception if it
> >>>> does not support temporary nodes.
> >>>>             The service may throw an InternalFault exception if an
> >>>> operation fails.
> >>>>             The service may throw a PermissionDenied exception
> >>>> if the
> >>>> user does not have permissions to perform the operation.
> >>>>
> >>>> Questions:
> >>>> - Should a properties structure be an optional parameter?
> >>>> - A user can always make a temporary node permanent by renaming
> >>>> it to
> >>>> something more meaningful.
> >>>>
> >>>>    Cheers,
> >>>>
> >>>>    Matthew
> >>>>
> >>>>
> >>>>
> >>>> Guy Rixon wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Use case for server-generated names: when clients working in
> >>>>> the same space
> >>>>> want to generate temporary files with unique names. Java
> >>>>> File.makeTempFile()
> >>>>> and all that. If we support this, it might deserve its own
> >>>>> operation with
> >>>>> different parameters from createNode.
> >>>>>
> >>>>> On Thu, 15 Jun 2006, Dave Morris wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Paul Harrison wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On 14.06.2006, at 14:01, Dave Morris wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> However, when creating a new node, it was agreed that the
> >>>>>>>> client
> >>>>>>>> would supply the name as a plain text string, and the server
> >>>>>>>> would
> >>>>>>>> convert this into the URI encoded identifier.
> >>>>>>>> This means that the server side code does the URI encoding,
> >>>>>>>> making
> >>>>>>>> it easier to verify that we get it right.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> The operations that create a new node (CreateNode,
> >>>>>>>> PushDataTo and
> >>>>>>>> PullDataTo) take the name of the new node, not the identifier.
> >>>>>>>> This gives us a way of distinguishing between import into an
> >>>>>>>> existing node (node URI) and import into a new node (node
> >>>>>>>> name).
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> also I think that there was also the idea that the server would
> >>>>>>> generate a name automatically so the URI could point to a
> >>>>>>> container...
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> The distinction still isn't as clear as I would like, but
> >>>>>>>> that is
> >>>>>>>> what is in the current document.
> >>>>>>>> If we want to change this, then we will need to modify the
> >>>>>>>> document.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> I think that the semantics of these operations are not still
> >>>>>>> clear as
> >>>>>>> currently implemented in the WSDL, and do need some work
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> I too was struggling with how to represent these multiple
> >>>>>> parameters in
> >>>>>> the experimental WSDL examples I posted last week.
> >>>>>> If they are causing problems, do we want to look at these
> >>>>>> again, and
> >>>>>> possibly simplify them.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> Server generated identifiers :
> >>>>>> The original reason for server generated identifiers dates
> >>>>>> back to when
> >>>>>> we had two separate namespaces, VOSpace with user defined
> >>>>>> names, and
> >>>>>> VOStore with server generated names.
> >>>>>> The VOStore service needed to generate the names in order to
> >>>>>> ensure that
> >>>>>> they were unique within that service.
> >>>>>>
> >>>>>> Now that we have brought everything into one VOSpace
> >>>>>> namespace, I don't
> >>>>>> think we need the server generated names any more.
> >>>>>> In which case, unless anyone has a compelling use case for
> >>>>>> this, I vote
> >>>>>> we drop it.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> Plain string name :
> >>>>>> I proposed the idea of using the separate name and URI in
> >>>>>> methods that
> >>>>>> created nodes, primarily because I wanted to make the server
> >>>>>> responsible
> >>>>>> for encoding the URI correctly.
> >>>>>> The client would just supply the name as a plain text string,
> >>>>>> and the
> >>>>>> server would encode it to create the full URI identifier.
> >>>>>>
> >>>>>> However, both of us have found problems trying to define a
> >>>>>> clear and
> >>>>>> concise WSDL that distinguishes between an import operation
> >>>>>> that creates
> >>>>>> a new node and one that imports data into an existing node. In
> >>>>>> which
> >>>>>> case, it looks like having the separate name parameter for
> >>>>>> creating a
> >>>>>> new node is causing us more problems than it is worth.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> For VoSpace-1.0 I propose we drop both the server generated
> >>>>>> names and
> >>>>>> the separate name as string parameter.
> >>>>>>
> >>>>>> 1) CreateNode takes a mandatory target URI of the new node,
> >>>>>> rather than
> >>>>>> the optional string name.
> >>>>>> The target URI cannot be null, and the service does not
> >>>>>> automatically
> >>>>>> generate new names.
> >>>>>> It is up to the client to create and encode the target URI
> >>>>>> correctly.
> >>>>>> If the server receives an invalid URI, it throws an Exception.
> >>>>>>
> >>>>>> 2) The two import methods also take a single URI parameter to
> >>>>>> identify
> >>>>>> the target node.
> >>>>>> The target URI cannot be null, and the service does not
> >>>>>> automatically
> >>>>>> generate new names.
> >>>>>> It is up to the client to create and encode the target URI
> >>>>>> correctly.
> >>>>>> If the server receives an invalid URI, it throws an Exception.
> >>>>>> If the target node already exists, then its contents will be
> >>>>>> replaced by
> >>>>>> the import.
> >>>>>> If the target node does not exist, then the import methods
> >>>>>> will create a
> >>>>>> new node and import the data into that.
> >>>>>> (this also implies that the <replace> flag is no longer needed
> >>>>>> either)
> >>>>>>
> >>>>>> Then, to make things symmetrical :
> >>>>>>
> >>>>>> 3) MoveNode takes two URIs, representing the source and
> >>>>>> destination.
> >>>>>> The source URI cannot be null and must point to an existing node.
> >>>>>> The destination URI cannot be null, and must NOT point to an
> >>>>>> existing node.
> >>>>>> If a node already exists with the destination URI, then the
> >>>>>> method
> >>>>>> throws a DuplicateNodeException.
> >>>>>> It is up to the client to create and encode the destination
> >>>>>> URI correctly.
> >>>>>> If the server receives an invalid URI, it throws an Exception.
> >>>>>>
> >>>>>> 4) CopyNode takes two URIs, representing the source and
> >>>>>> destination.
> >>>>>> The source URI cannot be null and must point to an existing node.
> >>>>>> The destination URI cannot be null, and must NOT point to an
> >>>>>> existing node.
> >>>>>> If a node already exists with the destination URI, then the
> >>>>>> method
> >>>>>> throws a DuplicateNodeException.
> >>>>>> It is up to the client to create and encode the destination
> >>>>>> URI correctly.
> >>>>>> If the server receives an invalid URI, it throws an Exception.
> >>>>>>
> >>>>>> To support client encoded URIs :
> >>>>>>
> >>>>>> 5) We need to add MalformedIdentifierException to the list of
> >>>>>> exceptions
> >>>>>> for all the methods that take URI parameters.
> >>>>>>
> >>>>>> Hopefully, this should make the service API and WSDL a lot
> >>>>>> clearer.
> >>>>>>
> >>>>>> One caveat :
> >>>>>> I would like to re-visit this when we look at v2.x, based on
> >>>>>> what we
> >>>>>> find using v1.0 in real applications.
> >>>>>>
> >>>>>> ----
> >>>>>>
> >>>>>> Matthew is right when he says that if we have any changes we
> >>>>>> should be
> >>>>>> discussing them in the document, and not the WSDL.
> >>>>>> The WSDL should reflect the specification as defined in the
> >>>>>> document,
> >>>>>> presenting it in a machine readable form.
> >>>>>>
> >>>>>> So, based on the fact that both Paul and I have both found
> >>>>>> problems in
> >>>>>> creating a clear and concise WSDL to represent this part of the
> >>>>>> specification and that the original use cases for the extra
> >>>>>> parameters
> >>>>>> are either no longer valid or not worth the hassle.
> >>>>>> I propose we make the above changes to the specification
> >>>>>> document, and
> >>>>>> then update the WSDL to match.
> >>>>>>
> >>>>>> Guy, Matthew, and Paul can you reply with 'accept' or 'reject'
> >>>>>> for the
> >>>>>> five changes outlined above.
> >>>>>> If everyone says yes, then we can update the document tomorrow
> >>>>>> and
> >>>>>> publish it as v0.22.
> >>>>>>
> >>>>>> I know this is a bit formal and possibly OTT, but I suspect
> >>>>>> that we will
> >>>>>> be making quite a few changes like this over the next few days.
> >>>>>> Making specific requests for individual changes to the
> >>>>>> document should
> >>>>>> make it easier to keep track of everything.
> >>>>>>
> >>>>>> I know there is at least one case where I found the list of
> >>>>>> exceptions
> >>>>>> was wrong on one of the methods, but right now I can't
> >>>>>> remember where it
> >>>>>> was.
> >>>>>> If I find it again I'll post another change request with the
> >>>>>> details.
> >>>>>>
> >>>>>> There are also a couple of questions / suggestions I would
> >>>>>> like to raise
> >>>>>> regarding data types and formats.
> >>>>>> I'll post another change request when I have worked out the
> >>>>>> details.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Dave
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Guy Rixon 				        gtr at ast.cam.ac.uk
> >>>>> Institute of Astronomy   	                Tel: +44-1223-337542
> >>>>> Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>> Guy Rixon 				        gtr at ast.cam.ac.uk
> >>> Institute of Astronomy   	                Tel: +44-1223-337542
> >>> Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> >>>
> >>>
> >>
> >
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523