OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: Fw: [wsrf] Proposed resolution to WSRF 174 - references to instances ofMDDs

Tim's consideration applies equally to my updated proposal [2]
My mental model (which I did not spell out correctly) was (d).

However, on reflection, I now wonder why we don't choose (e) and drop the
"name" attribute altogether. Its a little more work than (d) right now but
we end up with something simpler. Do we have a "reasonable" scenario in
which having multiple MetadataDescriptor elements per Definitions element
is useful?


Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK

             B                                                          To 
             07/04/2006 14:46                                           cc 
                                       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

 <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/@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
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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]