Re: WS-MEX and putting undifferentiated MEX sections

Related to this is the issue of what it means when the @Identifier 
attribute is missing from a MetadataSection.  For example, if someone does 
a GetMetadata w/o the @Identifier attribute, the server is free to return 
all metadata regardless of the @Identifier.  Should it return the 
@Identifier or not?  From reading the spec its free to add or remove it - 
it doesn't matter.  Is the client supposed to interpret anything from its 
absence or presence?  Similarly, what if there's a really anal client and 
it always does GetMetadata by specifying the @Identifier attribute - but 
what if the server doesn't have the @Identifier attribute defined (meaning 
it never returns it).  The client doesn't know this and will never get 
metadata back.

Overall, it seems like we need to be consistent on two points:
1 - when is there a @Identifier attribute associated with a piece of 
metadata on the server  (for metadata the does define how to calc it)
2 - when is the @Identifier attribute present in a MetadataSection

I think having the answer be "always" for both gives us the least chance 
for interop issues.

Let the optionality of @Identifier just be querying purposes.

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