Fw: [NEW ISSUE] WS-MEX: no way to create metadata

As further clarification to my note below:

Please ignore the 1st point  (irrelevant as metadata endpoints would be 
specific to dialect anyhow).

Possible example use cases for the 2nd point:
Assuming that the metadata is held remotely from the resource endpoint, 
perhaps there are occasions when it's advantageous for the resource 
endpoint to return a reference to the metadata endpoint.  E.g. If the 
metadata is duplicated in the client's security realm, perhaps the service 
would prefer clients to get it from their 'local' copy.  Or, if the 
metadata was likely to change, perhaps its advantageous for the client to 
have a direct reference to the metadata for updates rather than going via 
an intermediary resource endpoint all the time. 

thanks
Katy

----- Forwarded by Katy Warr/UK/IBM on 13/01/2009 11:19 -----

From:
Katy Warr/UK/IBM@IBMGB
To:
public-ws-resource-access@w3.org
Date:
12/01/2009 13:58
Subject:
Re: [NEW ISSUE] WS-MEX: no way to create metadata




For (2), I like the idea of collapsing specs for a simpler solution and I 
agree that this should be considered. Couple of points for when the issue 
comes to discussion though: 
- We'd need a way to establish the metadata dialect returned when a 
transfer.get() was targeted at a *metadata* endpoint (rather than targeted 
at the resource endpoint) 
- I guess that transfer.get('wsdl') targeted at the resource's endpoint 
should also be able to return a reference to the metadata endpoint (which 
can then be targeted with transfer.get), rather than returning the 
metadata itself. 
thanks 
Katy




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 












Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Received on Tuesday, 13 January 2009 11:24:40 UTC