Re: summary of soapbuilders discussion about inlining multirefs

 Asir,
 it's mainly the symmetry. The type information is useful on
primitive values and on structs, so I don't think we want to
forbid it on arrays. 8-)

                   Jacek Kopecky

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



On Wed, 31 Oct 2001, Asir S Vedamuthu wrote:

 > Jacek,
 >
 > Thank you for this description.
 >
 > Spec says that you don't have to specify both. That is good. But, what is
 > the rational for specifying both SOAP-ENC:arrayType and xsi:type for an
 > element containing an array value? What is your expectation from readers?
 >
 > 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 1:43 PM
 > Subject: Re: summary of soapbuilders discussion about inlining multirefs
 >
 >
 > Asir,
 >  consider the following:
 >
 > <person xsi:type="ns:WhoIsWhoInLiteratureRecord">
 >   <name xsi:type="xsd:string">Joe Q. Writer</name>
 >   <bibliography xsi:type="ns:BibliographyArray"
 >                 enc:arrayType="ns:BibliographyItem[1]">
 >     <item xsi:type="ns:BibliographyItem">
 >       ...
 >     </item>
 >   </bibliography>
 > </person>
 >
 >  And the following excerpt of the schema:
 >
 >  <complexType name="BibliographyArray" base="soapenc:Array">
 >    ...
 >  </complexType>
 >
 >  In this example every item's type is explicitly mentioned, but
 > since bibliography is an array, it also has the arrayType
 > attribute which is obligatory.
 >
 >  And I thought my sentence about hrefs and nils did not allow the
 > combination, but now I see it can be understood as that it does
 > allow href and xsi:nil together, so an additional sentence
 > correcting this would need to be inserted. 8-)
 >
 >  Take care,
 >
 >                    Jacek Kopecky
 >
 >                    Senior Architect, Systinet (formerly Idoox)
 >                    http://www.systinet.com/
 >
 >
 >
 > On Tue, 30 Oct 2001, Asir S Vedamuthu wrote:
 >
 >  > >  I think arrayType is not equivalent to xsi:type as it does
 >  > > not identify the schema type of the array, so I think
 >  > > xsi:type and arrayType can easily coexist.
 >  >
 >  > Really !! What for ??
 >  >
 >  > > Note that this rule forbids href and xsi:nil from
 >  > > occurring together as well.
 >  >
 >  > I don't think so. "href or xsi:nil" means 0 1, 1 0, 1 1 are valid. The
 > third
 >  > combination, both href and xsi:nil, is allowed.
 >  >
 >  > 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 1:11 PM
 >  > Subject: Re: summary of soapbuilders discussion about inlining multirefs
 >  >
 >  >
 >  > Asir,
 >  >  I think arrayType is not equivalent to xsi:type as it does not
 >  > identify the schema type of the array, so I think xsi:type and
 >  > arrayType can easily coexist.
 >  >  Thanks for pointing out xsi:nil which is very similar to href in
 >  > this issue.
 >  >  So my current version of the constraints would be:
 >  >
 >  >  "If an href or xsi:nil attribute is present, only these listed
 >  > attributes may be present as well: enc:position, actor,
 >  > mustUnderstand, encodingStyle. On data encoded using SOAP
 >  > Encoding, the encodingStyle attribute, when present, must have
 >  > the value of 'http://www.w3.org/2001/09/soap-encoding'."
 >  >
 >  >  Note that this rule forbids href and xsi:nil from occurring
 >  > together as well.
 >  >  I've added encodingStyle because if a serialization root, for
 >  > example a header, is a reference, we need to be able to say that
 >  > this element is in fact serialized according to our Encoding
 >  > rules. If the encodingStyle attribute has a value different from
 >  > the above, the href attribute and xsi:nil are to be interpreted
 >  > according to the rules of the other encoding, so it's not our
 >  > business and therefore the restriction above is not a limitation.
 >  >  I expect every other global attribute defined by the core should
 >  > be added to the list - if we define any other global attributes.
 >  >  Best regards,
 >  >
 >  >                    Jacek Kopecky
 >  >
 >  >                    Senior Architect, Systinet (formerly Idoox)
 >  >                    http://www.systinet.com/
 >  >
 >  >
 >  >
 >  > On Tue, 30 Oct 2001, Asir S Vedamuthu wrote:
 >  >
 >  >  > > 3) For illustration of the problem .. There are two
 >  >  > > possible solutions:
 >  >  >
 >  >  > This is a general problem and is not specific to references. Here is a
 >  > third
 >  >  > possible solution that addresses the general problem - specify
 >  > co-occurrence
 >  >  > constraints
 >  >  >
 >  >  > Co-occurrence constraints,
 >  >  >
 >  >  > (a) href | xsi:nil | xsi:type | SOAP-ENC:arrayType - only one of these
 >  >  > attributes must be present
 >  >  > (b) id must not be present if href or xsi:nil is present
 >  >  > (c) SOAP-ENC:offset must not be present if href, xsi:nil or xsi:type
 > is
 >  >  > present
 >  >  >
 >  >  > Regards, Asir
 >  >  >
 >  >  > ----- Original Message -----
 >  >  > From: "Jacek Kopecky" <jacek@idoox.com>
 >  >  > To: <xml-dist-app@w3.org>
 >  >  > Sent: Friday, October 19, 2001 8:21 AM
 >  >  > Subject: ETF: summary of soapbuilders discussion about inlining
 > multirefs
 >  >  >
 >  >  >
 >  >  > Hi all. 8-)
 >  >  >  Here is the summary of the discussion on soapbuilders [1] about
 >  >  > inlining multirefs, which could solve the issue #18 (and #121).
 >  >  >  There was a general agreement that allowing inlining the
 >  >  > referenced data would be good.
 >  >  >  There were various points that people were pointing out:
 >  >  >  1) maybe we should also disallow forward references
 >  >  >  2) referencing data that can be stripped out from the message
 >  >  >  3) attribute clashes on references
 >  >  >
 >  >  >  Now let me detail the points.
 >  >  >  1) Some people felt forward references might be bad, other felt
 >  >  > my original proposal disallowed forward references. I propose to
 >  >  > keep forward references because they allow references from
 >  >  > headers to body, which might be necessary for things like
 >  >  > XMLDSIG, although any other referencing mechanism (most probably
 >  >  > XML IDREF) could be used instead of SOAP Encoding referencing.
 >  >  >
 >  >  >  2) References from body to headers and references among headers
 >  >  > may lead to situations where the referenced data is removed from
 >  >  > the message. There are a few possible solutions to this (I'm not
 >  >  > saying the list is necessarily complete):
 >  >  >  a) Rely on application designers to do it right. This is not
 >  >  > recommendable.
 >  >  >  b) disallow references between "serialization trees", the roots
 >  >  > of "serialization trees" being each header block and the Body (or
 >  >  > for the sake of symmetry each body block, but this is not
 >  >  > necessary to solve problem 2). If we go this way we must allow
 >  >  > for e.g. the dig-sig header to point to anything using different
 >  >  > means from SOAP Encoding hrefs.
 >  >  >  c) "References in which the referenced data may disappear before
 >  >  > all the references (i.e. references between headers or a header
 >  >  > and the body), MUST be serialized as "independent" elements in
 >  >  > the <soap-env:Header/> element and they must contain an attribute
 >  >  > 'actor' with the value '.../none'. All other referenced data
 >  >  > SHOULD be serialied in-line." Quite complex but solving the
 >  >  > problem.
 >  >  >  Personally, I prefer b) over c) over a).
 >  >  >
 >  >  >  3) For illustration of the problem:
 >  >  > <a foo="bar" id="1">blah</a>
 >  >  > <b foo="baz" href="#1"/>
 >  >  > The problem is what is the value of b? There are two possible
 >  >  > solutions:
 >  >  >  a) merge attributes - prefer those from the accessor over those
 >  >  > from the referenced element,
 >  >  >  b) ignore attributes on the accessor except for a limited list
 >  >  > of exceptions: href, enc:position. (Might want to add actor and
 >  >  > mustUnderstand, but see my reasons against it in [2]).
 >  >  >  I recommend b), because of reasons in [3].
 >  >  >
 >  >  >  If any of my recommendations needs more discussion, let me know
 >  >  > which and I'll write a separate email so that a formal issue can
 >  >  > be formed, for it's better when an the issue list entry links to
 >  >  > a message with a single issue. 8-)
 >  >  >
 >  >  >  Best regards,
 >  >  >
 >  >  >                             Jacek Kopecky
 >  >  >
 >  >  >                             Idoox
 >  >  >                             http://www.idoox.com/
 >  >  >
 >  >  >
 >  >  > [1] http://groups.yahoo.com/group/soapbuilders/message/5557
 >  >  > [2] http://groups.yahoo.com/group/soapbuilders/message/5591
 >  >  > [3] http://groups.yahoo.com/group/soapbuilders/message/5580
 >  >  >
 >  >  >
 >  >  >
 >  >  >
 >  >  >
 >  >  >
 >  >
 >

Received on Wednesday, 31 October 2001 18:01:26 UTC