Re: [SOAP Encoding Issue] Most to least specific encodingStyles,HOW?

+1 to KISS. Has anyone a demonstrable need for support
for multiple encodings? Couldn't the encodingStyle attribute
be context sensitive (eg. it applies to the element on
which it is declared and all of its decendants until
a subsequent encodingStyle declaration is made)?

Cheers,

Chris

Asir S Vedamuthu wrote:

> Jacek,
> 
> Thank you for looking into this.
> 
> 
>>If it is useful for a receiver to know that this data was
>>serialized according to the subset (2), while other receivers
>>might just fall back to the general set (1) not knowing/caring
>>about the restriction, the multiplicity of encodingStyle might be
>>justified.
>>
> 
> As you said, this needs to be clarified with lots of text and examples.
> Also, per your description, then we need additional constraints,
> 
> - any most specific encodingStyle in the whitespace delimited list must be a
> valid restriction of the next encodingStyle in this list. BTW, I do not know
> what restriction means in this context.
> 
> - all of the encodingStyles in the whitespace delimited list must use the
> same data model (there is some contention if encodingStyle implicitly
> specifies a data model)
> 
> 
>>If it is useful for a receiver to know that this data
>>was serialized according to the subset (2)
>>
> 
> Are there any benefits in knowing that this data was serialized according to
> the subset?
> 
> Lets say a receiver implements only a subset of SOAP Encoding and likes to
> know if parts of the message were serialized using a subset. Per issue 48
> resolution [1], I do not believe that we encourage subsetting SOAP Encoding.
> It is in take it or leave it mode - "but if they claim conformance with the
> SOAP encoding they must pass the SOAP encoding conformance tests". Then this
> hypothetical receiver does not conform to SOAP Encoding.
> 
> 
> Like Rich and you, I vote for simple things and will be happy to see this go
> ..
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0242.html
> 
> 
> Regards, Asir
> 
> ----- Original Message -----
> From: "Jacek Kopecky" <jacek@systinet.com>
> To: "Asir S Vedamuthu" <asirv@webmethods.com>
> Cc: <xml-dist-app@w3.org>
> Sent: Tuesday, October 30, 2001 10:30 AM
> Subject: Re: [SOAP Encoding Issue] Most to least specific
> encodingStyles,HOW?
> 
> 
> Asir,
>  I personally never saw the need for the multiple encodingStyle
> values. The example in the spec hints at some kind of possible
> "restriction hierarchy" where for example we have a set of rules
> (encStyle 1) and a subset thereof (encStyle 2).
>  If it is useful for a receiver to know that this data was
> serialized according to the subset (2), while other receivers
> might just fall back to the general set (1) not knowing/caring
> about the restriction, the multiplicity of encodingStyle might be
> justified.
>  But I think we do need to clarify the use of multiple values in
> encodingStyle if we actually want to keep it.
>  You would hear from me no objection to removing encodingStyle
> multiplicity, though. The soapbuilder in me would be glad for
> this simplification of SOAP. 8-)
>  I don't think the scoping of encStyle solves the same problem as
> the "more specific" encoding applies in the whole scope of the
> attribute.
>  Best regards,
> 
>                    Jacek Kopecky
> 
>                    Senior Architect, Systinet (formerly Idoox)
>                    http://www.systinet.com/
> 
> 
> 
> On Tue, 30 Oct 2001, Asir S Vedamuthu wrote:
> 
>  > Issue
>  >
>  > SOAP uses encodingStyle attribute to indicate the encoding rules used for
>  > serializing parts of a SOAP message. encodingStyle attribute is a
> whitespace
>  > delimited list. Each item in the list is type anyURI, XML Schema built-in
>  > type. And, specification says that sets of rules should be listed in the
>  > order most specific to least specific.
>  >
>  > First, thus far I have not seen any implementations that support this,
> "sets
>  > of rules .. most specific to least specific". Have you seen any?
>  >
>  > Second, what does it mean when the spec says "most specific to least
>  > specific"? How will a machine figure out when to apply what?
>  >
>  > Third, per Jacek's e-mail [2], encodingStyle attribute implicitly
> specifies
>  > a data model - say object-graph data model, RDF, UML, etc. What does it
> mean
>  > to say that the data model appears as "most specific to least specific"?
> mm
>  > .. it is a changing data model. isn't it?
>  >
>  > Fourth, encodingStyle has a scope. Its scope is its owner element and
> that
>  > element's descendents. The scope of encodingStyle is similar to the scope
> of
>  > default namespace declarations. Using this feature, it is possible to
>  > specify different specific encodingStyle at various element information
>  > items in the SOAP message. If so, is there a need for specifying "most
>  > specific to least specific" at one element information item when the same
>  > thing can be achieved by specifying just one encodingStyle at various
>  > element information items?
>  >
>  > I request the ETF to investigate the following,
>  >
>  > (a) Is there a need for "most specific to least specific" encoding rules
> and
>  > changing data models?
>  > (b) Does the scope of the encodingStyle attribute solve the same problem?
>  > (c) For interoperability reasons, how can we better articulate this
> feature
>  > using more prose, details and examples?
>  > (d) How does the "most specific to least specific" encoding rules measure
>  > against our requirements and charter "a mechanism for serializing data
>  > representing non-syntactic data models in a manner that maximizes the
>  > interoperability of independently developed Web applications" [3]
>  >
>  > [1] http://www.w3.org/TR/2001/WD-soap12-part1-20011002/#soapencattr
>  > [2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0192.html
>  > [3] http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N400
>  >
>  > Regards,
>  >
>  > Asir S Vedamuthu
>  >
>  > webMethods, Inc.
>  > 703-460-2513 or asirv@webmethods.com
>  > http://www.webmethods.com/
>  >
> 
>

Received on Tuesday, 30 October 2001 11:22:01 UTC