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

["Murray, Bryan P." <bryan.murray@hp.com>]

If MetadataDescriptor is the root of the resource properties document,
what is the advantage of restricting a Definitions element to a single
MDD?

I like (b) the best.

Bryan 

-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com] 
Sent: Monday, April 24, 2006 6:52 AM
To: Murray, Bryan P.
Cc: David Snelling; Wilson, Kirk D; Tim Banks; wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Proposed resolution to WSRF 174 - references to
instances of MDDs





Attached is the most recent email to the TC on this topic.

This refers to a number of options for developing the core proposal
advanced in [1].

The attached email thread supports a solution based on the option (b)
enumerated by Tim at the foot of forwarded mail-thread.
In another thread [2] a solution based on Tim's (e) was proposed. This
proposed a change to the RMD schema such that a <Definitions> element
could only have a single <MetadataDescriptor> element.

A primary difference between (b) and (e) is that:
 - in (b) the <MetedataDescriptor> element is the root of the metadata
resource's RPDoc whereas
 - in (e) the <Definitions> element is the root of the metadata
resource's RPDoc and this contains a single resource property which is
the <MetadataDescriptor>

(b) requires the schema of the MetadataDescriptor element to be changed.
In psuedo schema terms, this would be a change from this:
<MetadataDescriptor
      name="xsd:NCName"
      interface="xsd:QName"
      wsdlLocation="pairs of xsd:anyUri"?
      {anyAttribute}* >

  <documentation />?
  <Property /> *
  {any}*
</MetadataDescriptor>

to this:

<MetadataDescriptor>
    <name>xsd:NCName</name>
     <interface>xsd:QName</interface>
      <wsdlLocation>pairs of xsd:anyUri</wsdlLocation>?
     <documentation />?
     <Property /> *
     {any}*
</MetadataDescriptor>

A new variation on (b) - lets call this (f) - could exploit the same
simplifiction as in (e) and restrict a <Definitions> element to
containing a single <MetadataDescriptor>. Unless we have valid use cases
for MDDs with multiple <MetadataDescriptor> elements then I think we
should certainly do this and so chose between this option (f) and (e).
If we do have valid use cases for MDDs with multiple
<MetadataDescriptor> elements then I think (b) is the clear winner.

I suggest we consider the requirement or not of multiple
<MetadataDescriptor> elements as part of this issue (WSRF 174).

I will raise a new issue to track the separate discussion we had in [2]
on the simplification of wsrmd:MetadataDescriptorLocation from
"wsrmd:PairsOfURIType" to "xsd:anyURI". The outcome of that issue should
not affect this issue.


[1]
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200604/
msg00015.html
[2]
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200604/
msg00036.html

Regards,
Ian Robinson



 

             "Murray, Bryan

             P."

             <bryan.murray@hp.
To 
             com>                      "Wilson, Kirk D"

                                       <Kirk.Wilson@ca.com>, "David

             12/04/2006 19:19          Snelling"

                                       <David.Snelling@UK.Fujitsu.com>

 
cc 
                                       Tim Banks/UK/IBM@IBMGB,

                                       <wsrf@lists.oasis-open.org>

 
Subject 
                                       RE: [wsrf] Proposed resolution to

                                       WSRF 174 - references to
instances  
                                       of MDDs

 

 

 

 

 

 





Yes, GetRP on 'Property' will return all Property elements. Use QueryRP
if you want a subset and the resource supports the operation.

As I suggested and Dave supports, we can change the definition of the
MetadataDescriptor element so there are no attributes on the root
element. These attributes are changed to elements. Then you can GetRP
the targetNamespace.

Bryan

-----Original Message-----
From: Wilson, Kirk D [mailto:Kirk.Wilson@ca.com]
Sent: Wednesday, April 12, 2006 7:39 AM
To: David Snelling; Murray, Bryan P.
Cc: Tim Banks; wsrf@lists.oasis-open.org
Subject: RE: [wsrf] Proposed resolution to WSRF 174 - references to
instances of MDDs

If I understand Bryan's proposal, then one could retrieve the MDD name
and interface via a simple GetResourceProperty; however, a GetRP on
Property would still return all the Property elements and the client
would need to parse through these.

Is that correct, Bryan?

Making the MDD the root element of the RP losses the targetnamespace
attribute.  Is that a problem?

Kirk Wilson
Architect, Development
Office of the CTO
603 823-7146


-----Original Message-----
From: David Snelling [mailto:David.Snelling@UK.Fujitsu.com]
Sent: Wednesday, April 12, 2006 5:48 AM
To: Murray, Bryan P.
Cc: Tim Banks; wsrf@lists.oasis-open.org
Subject: Re: [wsrf] Proposed resolution to WSRF 174 - references to
instances of MDDs

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