[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
I still don't understand how, given the following MDD lifted straight from
lines 298-314 of the spec, the targetNamespace attribute of the Definitions
element is represented in a derived metadata resource RPDoc.
<Definitions
xmlns=”http://docs.oasis-open.org/wsrf/rmd-1”
xmlns:id=”http://example.com/ns/Identification”
targetNamespace=”http://example.com/ns/Identification”>
<MetadataDescriptor
name=”IdentificationMetadataDescriptor”
interface=”id:Identification”
wsdlLocation=”http://example.com/ns/Identification
http://example.com/wsdl/Identification.wsdl” >
<Property name=”id:ResourceID”
mutability=”constant”
modifiability=”read-only” />
<Property name=”id:ResourceType”
mutability=”constant”
modifiability=”read-only” />
</MetadataDescriptor>
</Definitions>
If we want to successfully conclude this issue we need a concrete proposal
that illustrates:
1. precisely how the MetadataDescriptor schema needs to modified
2. precisely how the above RMDDocument instance is transformed into a
metadata resource RPDoc instance.
Regards,
Ian
"Murray, Bryan
P."
<bryan.murray@hp. To
com> Ian Robinson/UK/IBM@IBMGB
cc
01/05/2006 18:55 "David Snelling"
<David.Snelling@UK.Fujitsu.com>,
"Wilson, Kirk D"
<Kirk.Wilson@ca.com>, Tim
Banks/UK/IBM@IBMGB,
<wsrf@lists.oasis-open.org>
Subject
RE: [wsrf] Proposed resolution to
WSRF 174 - references to instances
of MDDs
Ian,
I am not sure I am understanding what you are saying. I will try to
restate it - let me know if I have it correct.
A MetadataDescriptor element will always be the root element of a
metadata resource. This element will always be in the rmd namespace.
This root element has a child element named 'interface' that indicates
the Qname of the portType for which this metadata document adds
additional information. The namespace portion of that portType Qname is
the namspace for the WSDL document in which the portType resides and is
probably different from the namespace of the resource property document
that the metadata document is describing. The namespace of the resource
property document can be discovered by accessing and observing the
namepsace portion of the value of the metadataDescriptor attribute on
the portType or by using GetResourcePropertyDocument on the resource and
observing the namespace of the root element.
I think this will work. It is a little difficult to find the namespace
that the metadata is describing, but there is a way to do so. It would
probably help a client to include the targetNamespace.
My understanding is that the metadata document will still use the
Definitions element for its root and have a targetNamespace attribute.
Is this correct?
Regarding one or several MetadataDescriptor child elements of a
Definitions element, the metadata document was designed to closely mimic
a WSDL document (root element is the same, MetadataDescriptor is roughly
equivalent to portType), thus, some designers may want the same
flexibility in being able to define multiple portTypes in one WSDL
document, and thus want to be able to define multiple MetadataDescriptor
elements in one metadata document. It seems artificial and short sighted
to limit the number of MetadataDescriptor elements because our current
myopic view of the world does not need more than one.
Allowing more than one MetadataDescriptor element does not change what
we see as a metadata resource, and only offers more than one
MetadataDescriptor element in a metadata document. Developers are
already familiar with how to find one of several elements with the same
name, as they iterate through a WSDL document to find a specific
portType or binding element. I do not feel that allowing more than one
MetadataDescriptor element adds significant complexity since developers
already know how to handle more than one portType element.
Bryan
-----Original Message-----
From: Ian Robinson [mailto:ian_robinson@uk.ibm.com]
Sent: Sunday, April 30, 2006 11:53 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
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]