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

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 10:57:45 UTC