Re: summary of soapbuilders discussion about inlining multirefs

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 15:17:38 UTC