RE: Features: required implementation and use (was Re: Describing which blobs are to be optimized.)

> I wonder whether a better approach might be to 
> first derive a subtype of base64Binary that uses 
> the pattern facet (ugh!) to ensure that the lexical 
> form is canonical.

I thought that it is little more than the canonical lexical form - "Element
content in base64Binary canonical lexical representation; content MUST not
contain any whitespace characters, preceding, inline with or following the
non-whitespace content [1]". May be, that is what you meant.

> Then say in WSDL:  you can MTOM optimize anything you 
> like, but elements of this type are guaranteed to be 
> optimizable

+1 to "guaranteed to be optimizable", if there is such a subtype of
base64Binary.

Reading thru this thread, possibilities are, sender/receiver:
(a) knows what to optimize (magic
(b) learns what to optimize (say, from a schema (via hints)
(c) optimizes per directions from a user
(d) determines on the fly - walks thru an infoset hunting for element
content to be optimized

First, I am in favor of spelling out the minimum (that is, leave this to the
discretion of the sender/receiver).

But, if WSDL does not provide hints on what parts may be optimized then (b)
is ruled out. May be, that is OK.

[1]
http://www.w3.org/2000/xp/Group/3/06/Attachments/XOP.html#xop_processing_mod
el

Regards,
Asir S Vedamuthu
asirv at webmethods dot com
http://www.webmethods.com/

-----Original Message-----
From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of noah_mendelsohn@us.ibm.com
Sent: Wednesday, June 09, 2004 3:02 PM
To: Martin Gudgin
Cc: gdaniels@sonicsoftware.com; hugo@w3.org; Jonathan Marsh;
Marc.Hadley@Sun.COM; paul.downey@bt.com; www-ws-desc@w3.org;
xml-dist-app@w3.org
Subject: RE: Features: required implementation and use (was Re: Describing
which blobs are to be optimized.)



Martin Gudgin writes:

>> Essentially any element in the schema description of 
>> the message which is xs:base64Binary ( or a type 
>> derived therefrom ) is a potential separate MIME part.

First of all, I think you need to enforce the canonical form, since 
base64Binary has multiple forms.

In other respects, this may be a sensible way to go in WSDL, but for the 
record SOAP and MTOM don't require use of the schema typing system.  MTOM 
just requires that the element have content that is in a legal lexical 
form of base64Binary.  Given that WSDL is schema-based, doing this with 
schema types may be the right thing to do.  Consider, on the other hand, a 
schema wildcard in a WSDL interface.  Are we sure we can't MTOM optimize 
something validated by that? 

As a really obscure case, I don't think MTOM itself prohibits optimization 
of:

        <e xsi:type="xsd:string">....base64Binary canonical form 
here...</e>

Whether this is good practice is an interesting question, but MTOM doesn't 
forbit it I think.  Now relate this to the wildcard question, particularly 
a "skip" wildcard.  Do you really want to require that xsi:type be checked 
in a subtree where validation is not being attempted?   Even if you don't 
like the above construction, do you want to force processors to detect it. 
 In other words, are you sure you want WSDL to even try and control use of 
MTOM at the element level? 

I wonder whether a better approach might be to first derive a subtype of 
base64Binary that uses the pattern facet (ugh!) to ensure that the lexical 
form is canonical.  Then say in WSDL:  you can MTOM optimize anything you 
like, but elements of this type are guaranteed to be optimizable.

I'm not pushing one answer or another to these questions, just pointing 
out that the options allowed by MTOM may be more subtle than one might 
notice at first.  I think that the WSDL group would do well to think 
through these cases and come to careful conclusions about them. 

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 9 June 2004 16:06:01 UTC