[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]