[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 ofMDDs
Having <targetNamespace> as a child element of MetadataDescriptor is taking
this too far. The resolution to this issue needs to state that the xmlns
for a <MetadataDescriptor> in a MDD needs to be preserved in any derived
metadata resource RPDoc; both should use XML namespaces in the normal way.
If any WS-Resource requester needs to determine the xmlns of the root
element of an RPDoc then it should use GetResourcePropertyDocument.
Assuming this assertion is accepted, then there is one primary difference
between the options 'b' and 'f' - 'f' restricts a MDD to a single
MetadataDescriptor element and eliminates the <name> child element
(previously attribute) from <MetadataDescriptor>.
Bryan - you asked:
> what is the advantage of restricting a Definitions element to a single
MDD?
The advantage is that we have not a single scenario where it makes sense to
have more than one (that I am aware of). The "flexibility" of multiple
MetadataDescriptor elements which have to be qualified by name seems an
unnecessary complication. Please correct me if this is wrong. But if not, I
tend towards option 'f' for simplicity.
Regards,
Ian Robinson
STSM, WebSphere Messaging and Transactions Architect
IBM Hursley Lab, UK
ian_robinson@uk.ibm.com
"Murray, Bryan
P."
<bryan.murray@hp. To
com> Tim Banks/UK/IBM@IBMGB
cc
25/04/2006 22:43 <wsrf@lists.oasis-open.org>, "David
Snelling"
<David.Snelling@UK.Fujitsu.com>,
"Wilson, Kirk D"
<Kirk.Wilson@ca.com>, Ian
Robinson/UK/IBM@IBMGB
Subject
RE: [wsrf] Proposed resolution to
WSRF 174 - references to instances
of MDDs
Tim,
This whole discussion began when Dave brought up his use case for
"dynamic" metadata due to the existance of resources having new
properties created at runtime. Thus, we allowed the metadata property to
reference a live resource instead of a static document. This does not
mean the metadata property is required nor that the metadata document no
longer exists. My understanding is that the document must exist in order
to support design time use of metadata.
I believe you are right that the targetNamespace property should be
added to the metadata resource to allow a client of that metadata
resource to learn which namespace it is associated with. This namespace
should certainly be the same as the namespace used in the metadata doc,
but it has nothing to do with a WSDL portType and a reference to the
metadata doc. The WSDL portType refers to the metadata doc (it is just a
URL and QName), not the metadata resource (which requires an EPR as a
reference). At runtime, the metadata property refers to the metadata
resource, not the metadata doc.
The metadata resource is just like any other resource. It happens to
have a root element named rmd:MetadataDescriptor and a bunch of
properties that describe the metadata of another resource. But there is
no XML magic for referencing this resource - it uses an EPR just like
any other resource. This EPR can use any value for the wsa:Address and
wsa:ReferenceParameters fields that is reasonable for its deployment.
Bryan
-----Original Message-----
From: Tim Banks [mailto:tim_banks@uk.ibm.com]
Sent: Tuesday, April 25, 2006 2:48 AM
To: Murray, Bryan P.
Cc: wsrf@lists.oasis-open.org; David Snelling; Wilson, Kirk D; Ian
Robinson
Subject: RE: [wsrf] Proposed resolution to WSRF 174 - references to
instances of MDDs
Hi Bryan,
As described by Ian in [1]...
> (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>
>
But... (b) also requires the declaration of the targetNamespace for the
Metadata descriptor, without which it cannot be referenced (from a
portType) via a Qname. So, is this targetNamespace information also to
be provided as a child element, like this?
<MetadataDescriptor>
>>> <targetNamespace>xsd:anyUri</targetNamespace>
<name>xsd:NCName</name>
<interface>xsd:QName</interface>
<wsdlLocation>pairs of xsd:anyUri</wsdlLocation>?
<documentation />?
<Property /> *
{any}*
</MetadataDescriptor>
I worry that this is getting into the realms of extreme-XML, and can
find no precedent for this kind of construction; can you help me?
Regards, Tim Banks.
[1]
http://www.oasis-open.org/apps/org/workgroup/wsrf/email/archives/200604/
msg00051.html
------------------------------------------------------------------------
------------------------------------------------------------------------
--------------
"Murray, Bryan P." <bryan.murray@hp.com> wrote on 24/04/2006 21:55:16:
> 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
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]