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

Jacek,

This suggests that we are jamming two features into 1 - specifying in-scope
encodingStyle and declaring one encodingStyle is a valid restriction of
another encodingStyle. The latter needs to be declared only once. However,
per status quo, if the restricted encodingStyle is specified multiple times
at various element info items, then we are forced to specify that the
restricted encodingStyle is a valid restriction of another encodingStyle
multiple times.

Regards, Asir

----- Original Message -----
From: "Jacek Kopecky" <jacek@systinet.com>
To: "Christopher Ferris" <chris.ferris@sun.com>
Cc: "Asir S Vedamuthu" <asirv@webmethods.com>; <xml-dist-app@w3.org>
Sent: Tuesday, October 30, 2001 12:43 PM
Subject: Re: [SOAP Encoding Issue] Most to least specific
encodingStyles,HOW?


Chris,
 encodingStyle has exactly the scoping you want. 8-)
 Multiple encodings here is not meant as multiple _different_
encodings, it's more like "the data is encoded using these rules,
but actually using these - more specific - rules, too".
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Tue, 30 Oct 2001, Christopher Ferris wrote:

 > +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 12:56:31 UTC