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

> I propose we all just say "we suggest that
> encodingStyle attribute be made single-value
> because the other way is unnecessarily complex." 8-)

I agree

Asir

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


Asir,
 we are not declaring that one encodingStyle is a valid
restriction of another, we're simply assuming it, it's a
prerequisite for the two values to be able to coexist in one
encodingStyle attribute. 8-)
 Sure the information may seem redundant and we might want to
declare the encodingStyle restrictions in a different place and
put into encodingStyle only the most specific, but I think this
would be overkill.
 Anyway, since we seem to be wandering into something deep here,
I propose we all just say "we suggest that encodingStyle
attribute be made single-value because the other way is
unnecessarily complex." 8-)
 Take care,

                   Jacek Kopecky

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



On Tue, 30 Oct 2001, Asir S Vedamuthu wrote:

 > 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 13:28:53 UTC