Re: [wsrf] Proposed resolution to WSRF 174 - references to instances of MDDs

[David Snelling <David.Snelling@UK.Fujitsu.com>]

Folks,

On 12 Apr 2006, at 01:15, Murray, Bryan P. wrote:

> The downside is that parts of this resource are only accessible via
> GetResourcePropertyDocument and QueryResourceProperties - both  
> optional
> operations. I think the ways to solve this are to either require that
> GetRPD be supported for this type of resource, or to move the root
> element attributes into child elements of the root. The move of
> attributes could either be done just for the stand-alone resource  
> or for
> both the resource and the RMD doc.

I support the later option. If we can shape the RMD document so that  
the minimum implementation of a WS-resource can get at the elements  
using only GetResourceproperty, I think we wind up with a tighter  
match up. It would be advantageous if both versions of the document  
were the same.

>
> Bryan
>
> -----Original Message-----
> From: Tim Banks [mailto:tim_banks@uk.ibm.com]
> Sent: Friday, April 07, 2006 6:46 AM
> To: wsrf@lists.oasis-open.org
> Subject: Fw: [wsrf] Proposed resolution to WSRF 174 - references to
> instances of MDDs
>
> Ian's initial proposal [1]  was for the following type to be used in a
> ResourceProperty
>
>
>  <xsd:complexType name="MetadataDescriptorRefType" >
>>         <xsd:complexContent>
>>           <xsd:extension base="wsa:EndpointReferenceType">
>>           </xsd:extension>
>>         </xsd:complexContent>
>>       </xsd:complexType>
>
>
> and for this type to be used in a resource Property in place of the
> current type which has attributes:
> /wsrmd:MetadataDescriptorRef/@name
> /wsrmd:MetadataDescriptorRef/@metadataDescriptorLocation   ( which  
> is a
> list of Pairs of URIs)
>
> As it currently stands, the proposal needs more information:  it needs
> the name of a metadataDescriptor element within the Definitions  
> that are
> referenced by the EPR. However, this would look strange, because only
> one MDD element is used per WS Resource instance;  why does the  
> resource
> property for that instance point at a document that contains  
> extraneous
> MDDs?   We have a few of ways to go that could straighten out the
> picture.
>
> a) Add the "name"  back into the MetadataDescriptorRefType  and let  
> the
> client parse the document to find the right MDD. As I said, this looks
> strange.
> b) Make the EPR point at a MDD  - except that the MDD currently  
> gets its
> namespace from the targetnamespace on the enclosing Definitions  
> element.
> This doesn't sound good.
> c) Make the EPR point at a Definitions element that contains only the
> MDD of interest - that is, it's a filtered view of the complete
> Definitions, but does that matter? I think it is a trap waiting to  
> catch
> people out, since the schema checkers can't police the restriction.
> d) Make the EPR point at a new "DefinitionsRP" element that contains
> only the MDD of interest and carries a targetnamespace attribute -  
> that
> is, it's the same as the Definitions except that it has a  
> "maxOccurs=1"
> for the child MDD elements.  *This looks like the cleanest option  
> to me*
> e) Constrain the Definitions element to always contain a single MDD.
> This simplifies the whole thing, but what function does the name
> attribute on
> the metadata descriptor have?   Are we saying that it's redundant, and
> all
> MDDs should be in their own distinct namespaces?  Or, are there to be
> multiple Definitions elements in different files, all using the same
> namespace, in which case the MDD "name"  is still useful, but  
> allows the
> possibility of getting name collisions.   In any case, we would  
> have to
> remove the attribute of the WSDL portType which currently indicates a
> name
> - that information is redundant, since the metadatadescriptorLocation
> would point at a definitions element and its contained
> metadatadescriptor.
>
>
> Regards, Tim Banks.
>
>
>
> [1]
> http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/ 
> 200604/
> msg00015.html
>
>

Take care:

       David Snelling David . Snelling . UK . Fujitsu . com
       Fujitsu Laboartories of Europe