- From: Doug Davis <dug@us.ibm.com>
- Date: Mon, 14 Feb 2011 14:57:02 -0500
- To: Gilbert Pilz <gilbert.pilz@oracle.com>
- Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OFCE13A9BE.BBAC9148-ON85257837.006D2288-85257837.006D9792@us.ibm.com>
Gilbert Pilz <gilbert.pilz@oracle.com> wrote on 02/14/2011 10:22:31 AM:
> You and I are in complete agreement about this, except for the
> "unless a particular Metadata type does not define an Identifier".
> I'm having trouble figuring out what that means in the context of
> clients and services that may have no, or only partial understanding
> of the types of metadata they are dealing with. How can an
I thinking we could follow the pattern that who ever mints the Metadata
MUST know enough about it to fill in the @Identifier attribute. And
we could even make @Identifier a required attribute on MetadataSections,
even if its value is "". Although, I guess we could claim that "" ==
absent.
> implementation which doesn't recognize the type of the metadata (i.
> e. the value of the @Dialect attribute is unknown to it) be expected
> to know whether or not that kind metadata does or doesn't define an
> Identifier?
>
> I think what you might be saying is that we can expect these things
> to be consistent. When dealing with a metadata type for which no
> Identifier is defined, no client will ever do a GetMetadata with an
> @Identifier, because there can be no valid value for this attribute.
Yes.
> What this tells me is that I can treat metadata that has been put
> with no @Identifier as if it had a special @Identifier value that
> never matches any other @Identifier value.
Not sure. I prefer to think of it as a Put MUST include the
@Identifier attribute ("" or not) - and that's the value that will
always be associated with it.
> ~ gp
>
> On 2/13/2011 3:28 PM, Doug Davis wrote:
>
> If we adopt my proposal the client will not able to Put metadata w/o
> the @Identifier attribute - which means your scenario will not
> happen and the ambiguity will be gone. Dialect and Identifier are
> no longer optional in MetadataSections (unless a particular Metadata
> type does not define an Identifier). @Identifier is only optional
> on the GetMetadata request - just as a query mechanism - nothing more.
>
> thanks
> -Doug
> ______________________________________________________
> STSM | Standards Architect | IBM Software Group
> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
>
> Gilbert Pilz <gilbert.pilz@oracle.com>
> 02/13/2011 06:01 PM
>
> To
>
> Doug Davis/Raleigh/IBM@IBMUS
>
> cc
>
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
>
> Subject
>
> Re: WS-MEX and putting undifferentiated MEX sections
>
>
>
>
> I'm still a bit puzzled on exactly how to implement PutMetadata and
> subsequent GetMetadata request - it's a question of matching.
>
> Suppose a client sends one or more PutMetadatas that contained one
> or more MetadataSections without an @Identifier. After this some
> client does a GetMetadata with a mex/Dialect/@Identifier="foo".
> Should or shouldn't the service return the metadata hunks that have
> no identifier? It seems that either way you cut it, you could be
> doing the wrong thing. If you don't return the unidentified hunks
> you could be "wrong" in the sense that one or more of them really
> does correspond to "foo". If do return the unidentified hunks, you
> could confuse the client as they may not have anything to do with "foo".
>
> What makes this even more troublesome is that the client that put to
> unidentified hunks may not know how to figure out what the
> identifier was for that metadata, but the client that is getting the
> unidentified hunks may know how to ID them.
>
> ~ gp
>
> On 2/13/2011 1:50 PM, Doug Davis wrote:
>
> The MEX spec is pretty consistent in that it talks about the
> @Identifier attribute being optional on the MetadataSection element
> - but _if_ present that it must be some dialect specific value. EVD
> follows this rule too. If we believe that its asking too much for
> the service to determine the @Identifier value for an incoming piece
> of metadata (so that, like your example shows, people can query by
> the @Identifier later on) then I would think it would asking too
> much for a client to do it too. Take the case of a generic MEX
> client that is trying to move metadata from one service to another -
> it might Get metadata w/o the @Identifier attribute but then its
> expected to add it before it did the Put.
>
> What if we took a different approach. What if we required the
> @Identifier attribute to always be present on a MetadataSection
> element _if_ the value is defined for that type of metadata. So, in
> our world, it MUST always be present for wsdl, xsd, policy and evd.
> However, @Identifier would still be optional for queries
> (GetMetadata/Dialect elements). By this I mean, when someone does a
> GetMetadata they are free to leave it out of the query - it just
> means they don't care about its value. However, the result MUST
> have the @Identifier set. In other words, @Identifier is only
> optional on a MetadataSection element IFF the metadata type doesn't
> define how to calculate it - and in those cases its ALWAYS absent.
>
> The only other option I can see is to remove @Identifier all
> together - and if we really wanted people to be able to filter
> their queries then let them pass in an XPath expression on the
> GetMetadata - then they can filter by anything they want. But that
> might be too big of a change.
>
> thanks
> -Doug
> ______________________________________________________
> STSM | Standards Architect | IBM Software Group
> (919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
> The more I'm around some people, the more I like my dog.
>
> Gilbert Pilz <gilbert.pilz@oracle.com>
> Sent by: public-ws-resource-access-request@w3.org
> 02/13/2011 03:46 PM
>
> To
>
> "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
>
> cc
>
> Subject
>
> WS-MEX and putting undifferentiated MEX sections
>
>
>
>
>
>
>
> Suppose a MEX-enabled service is presented with the following
> request (SOAP envelope omitted for brevity):
>
> <mex:PutMetadata>
> <mex:Metadata>
> <mex:MetadataSection Dialect="wsevd:EventDescriptions">
> <wsevd:EventDescriptions targetNamespace="http://www.
> w3.org/2002/ws/ra/test/scenario"
> xmlns:sce="http://www.w3.
> org/2002/ws/ra/test/scenario"
> xmlns:wsevd="http://www.w3.
> org/2011/01/ws-evd"
> xmlns:xs="http://www.w3.
> org/2001/XMLSchema">
>
> ...
>
> </wsevd:EventDescriptions>
> </mex:MetadataSection>
> </mex:Metadata>
> </mex:PutMetadata>
>
> Notice how the above request does NOT contain an @Identifier on the
> MetadataSection element. As far as I can tell, this is both schema
> valid and spec conformant (the language of Section 6.3 PutMetadata
> seems to hint that both @Dialect and @Identifier are expected, but
> nowhere does it state that @Identifier is required).
>
> You can probably guess where this is going; what if, subsequent to
> this request, you receive the following request
>
> <mex:GetMetadata>
> <mex:Dialect Type="wsevd:EventDescriptions"
> Identifier="http://www.w3.org/2002/ws/ra/test/scenario"
> Content="http://www.w3.org/2011/01/ws-
> mex/Content/Metadata"/>
> </ws:GetMetadata>
>
> The issuer of such a request might reasonably expect to receive the
> EventDescriptions from the previous PutMetadata operation, but how
> is the MEX implementation supposed to know that the @Identifier for
> the EVD (supplied in the PutMetadata) is "http://www.w3.
> org/2002/ws/ra/test/scenario"? You could build handlers that
> recognize various @Dialect values and know how to pull the relevant
> identifier out of the metadata itself, but this isn't a tractable
> general solution.
>
> I think we need to require that MetadaSections in the Metadata
> element use in a PutMetadata contain an @Identifier. I propose we
> add the following sentence to the end of the first paragraph of the
> description of [Body]/mex:PutMetadata/mex:Metadata:
> The mex:MetadataSections of this mex:Metadata element are REQUIRED
> to contain the @Identifier attribute (in addition to the mandatory
> @Dialect attribute).
> ~ gp
>
>
>
Received on Monday, 14 February 2011 19:58:38 UTC