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