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

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

When we discussed changing the metadata descriptor property to an EPR, I
understood Dave's use case to mean that this EPR would reference a
WSRF-RP conformant resource which possibly exposes GetRP, GetMRP, SetRP,
QueryRP, etc.

As an EPR to a resource, I see no need to add extra attributes to this
property. If you want to access it, use the WS-Addressing rules to use
an EPR to format a message to the resource and send it using one of the
supported operations.

I also do not think that just because we have an EPR to such a resource
that it has any effect upon the shape of an RMD doc. I think an RMD doc
still contains a Definitions element with several MetadataDescriptor
child elements. I think an RMD doc is retrievable via some other means
such as HTTP GET or WS-MetadataExchange. However, (an assumption on my
part) I believe the resource referenced by the above described property
should either be just a MetadataDescriptor element, or something else
morphed from the contents of a MD element. There are certainly a lot of
benefits to having the resource properties document for the metadata be
<rmd:MetadataDescriptor/> straight out of the schema for RMD.

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.

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