Hi,
I do not think that this is what Dave is suggesting: for the import methods, he has: "if the target node does not exist, then the import methods will create a new node and import the data into that." I think that the same behaviour is implied for copyNode and that it just has failed to be stated explicitly.
Cheers,
Matthew
Paul Harrison wrote:
> I should have chosen my words more carefully - I did not mean any
> formal "overloading" in the wsdl sense, but simply having a
> xsd:choice in the parameter set, though I can see that this is
> probably best avoided as I can see that it might not map too well
> onto the "pseudo rpc" that .NET transforms the doc/literal/wrapped
> into when presented to the programmer. It would still be very useful
> if someone could take the wsdl and run it through a .Net code generator.
>
> So yes go with another method CreateUniqueNode
>
> However, I am still unhappy about the use of CreateNode in VOSpace
> 1.0 - it seems to be leading Dave to what to produce complicated
> semantics for the data manipulation methods in his 5 point proposal
> in the start of this thread. He has it illegal for the target URI of
> these operations *NOT* to point to an existing node - this means that
> createNode has to be executed before a copyNode for instance - the
> unix analogy is that you have to do a "touch" before every "cp" -
> this seems perverse to say the least. I think that it would be far
> better if the opposite behaviour was the default - i.e. the data
> manipulation operations simply create the target node if it does not
> exist. We can set the "overwrite policy" to "don't overwrite - throw
> fault" by default with an optional flag to force the overwrite
> (permissions allowing of course).
>
> Paul.
>
> On 20.06.2006, at 09:31, Guy Rixon wrote:
>
>> 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
>
>
Received on 2006-06-20Z11:32:39