Loading ...
Sorry, an error occurred while loading the content.

Re: [soapbuilders] What if multirefs were all inlined?

Expand Messages
  • Jacek Kopecky
    Pete, in connection with the solution no. 1 to the second problem, the proposal is not to _allow_ inlining of multirefs, it s to _require_ inlining. Depending
    Message 1 of 28 , Oct 12, 2001
    • 0 Attachment
      Pete,
      in connection with the solution no. 1 to the second problem, the
      proposal is not to _allow_ inlining of multirefs, it's to
      _require_ inlining. Depending on how we define the term
      "serialization tree" and where it roots, in my idea of the
      definition the "independent elements" would ge outside the
      serialization tree.
      As for overwriting all attributes on "data" by attribues present
      on "accessor", it feels to me that it may have catches, but that
      it probably would be the simplest solution and it would work,
      provided that our encoding rules don't allow data attributes,
      i.e. attributes whose value contributes to the value of the
      accessor. For example:
      <a id="c" xml:lang="en_us">hello</a>
      <b href="#c" xml:lang="de" />
      or even
      <a id="c" xsi:type="string">1234</a>
      <b href="#c" xsi:type="int" />
      So I'd rather go with listing the attributes allowable on
      referencing accesors, and the list would probably look like
      [href, enc:position].

      Jacek Kopecky

      Idoox
      http://www.idoox.com/



      On Fri, 12 Oct 2001, Pete Hendry wrote:

      >
      > > Href before ID probably needn't be allowed, the encoding rules
      > > would have to state that there can be no forward references.
      >
      > It is currently permitted and so probably supported by most
      > implementations. Even though the proposal is that multirefs
      > MAY be serialized inline, the current way of doing it is
      > still valid. Currently a multirefs can come at the end of
      > the Body allowing forward references. Is there any reason
      > to change this?
      >
      > > 1) forbidding cross-linking between "serialization trees" and
      > > defining strict points where such "serialization trees" root;
      >
      > I'm with this one. Still to see a realistic use-case of why
      > you would want to do this.
      >
      > > 2) making referencing part of the core SOAP, on the same level
      > > as the processing model, and requiring that such cases be handled
      > > when removing the header etc. This would probably be helped by
      > > namespace-qualifying the href and id attributes. This would be
      > > very backwards-incompatible and the handling could be quite
      > > complex.
      >
      > Complex, yep.
      >
      > > 3) ignore it.
      > > I suggest 1 or 3 even though 2 may be the cleanest. 8-)
      > >
      >
      > I think 1 is as clean as 2. 3 is not really an answer for interop.
      >
      > > The attribute clashes you show are actually not there if we
      > > clarify that, e.g. the attribute enc:position is on the
      > > "accessor" and not on the "data", so
      > > <a enc:position="[1]" id="c"/> <!-- accessor and data -->
      > > <b enc:position="[2]" href="#c"/> <!-- just an accessor -->
      > > And a reference href="#c" references the data, not the accessor.
      > > 8-)
      > >
      >
      > This is the case. However, if serializing inline then you could get
      >
      > <a enc:position="[1]" id="c">string</a>
      > <b enc:position="[2]" href="#c" />
      >
      > If this is not allowed then array elements should not be
      > serialized inline and we would have to fall back to the
      > current scheme. I prefer that *all* attributes in the
      > accessor are merged *over* those in the data. To me this
      > seems like a more natural and future proof way of
      > proceeding than the current list of rules for which
      > attributes can appear on a href, which on the data and how
      > they interact. This will have to be maintained and will be
      > affected by other changes such as the one we are
      > discussing. The above example breaks the current rules I
      > believe but at the same time prevents a general
      > implementation for the proposed inlining.
      >
      > Pete
      >
      >
      > -----------------------------------------------------------------
      > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
      >
      > To unsubscribe from this group, send an email to:
      > soapbuilders-unsubscribe@yahoogroups.com
      >
      >
      >
      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      >
      >
    • Robert van Engelen
      ... I would like to add that in certain cases it is impossible to avoid forward references. For example, consider John
      Message 2 of 28 , Oct 12, 2001
      • 0 Attachment
        > > Href before ID probably needn't be allowed, the encoding rules
        > > would have to state that there can be no forward references.
        >
        > It is currently permitted and so probably supported by most implementations. Even though the proposal is that multirefs
        > MAY be serialized inline, the current way of doing it is still valid. Currently a multirefs can come at the end of the

        I would like to add that in certain cases it is impossible to avoid forward
        references. For example, consider

        <ns:person id="1">
        <name>John</name>
        <address href="#2"/>
        </ns:person>
        <ns:address id="2">
        <street>Main</street>
        <city>Mytown</city>
        <livesAt href="#1"/>
        </ns:address>

        or

        <ns:struct>
        <part id="3">
        <name href="#4"/>
        </part>
        <product>
        <part href="#3"/>
        <name id="4">A</name>
        </product>
        </ns:struct>

        I am all for allowing embedded elements to be id'ed to support inline
        serialization of multirefs!

        > <a enc:position="[1]" id="c">string</a>
        > <b enc:position="[2]" href="#c" />

        With respect to earier discussions: I don't think there is a problem with this
        serialization as long as it is agreed upon that the href refers a *value* and
        not to the XML element with attributes and the value. So in this case, value
        "string" is placed at position="[2]". Should this convention be
        added/mentioned in the SOAP standard?

        - Regards, Robert
      • Rich Salz
        Saying you can inline at the first instance is a small simplification. Outlawing forward references is a big limitation. For example, it would make it
        Message 3 of 28 , Oct 12, 2001
        • 0 Attachment
          Saying "you can inline at the first instance" is a small
          simplification. Outlawing forward references is a big limitation. For
          example, it would make it impossible to add a XMLDSIG header element.
          /r$
          --
          Zolera Systems, Securing web services (XML, SOAP, Signatures,
          Encryption)
          http://www.zolera.com
        • Pete Hendry
          ... The problem is we can t predict what the developer wants and if we list the attributes which are *allowed* then we limit the developers scope. For example,
          Message 4 of 28 , Oct 12, 2001
          • 0 Attachment
            > As for overwriting all attributes on "data" by attribues present
            > on "accessor", it feels to me that it may have catches, but that
            > it probably would be the simplest solution and it would work,
            > provided that our encoding rules don't allow data attributes,
            > i.e. attributes whose value contributes to the value of the
            > accessor. For example:
            > <a id="c" xml:lang="en_us">hello</a>
            > <b href="#c" xml:lang="de" />
            > or even
            > <a id="c" xsi:type="string">1234</a>
            > <b href="#c" xsi:type="int" />
            > So I'd rather go with listing the attributes allowable on
            > referencing accesors, and the list would probably look like
            > [href, enc:position].
            >

            The problem is we can't predict what the developer wants and if we list the attributes which are *allowed* then we limit
            the developers scope. For example, I could define a complex type with attribute "aX". Why should the SOAP spec disallow
            me from saying

            <a id="a" tns:aX="xxx">string</a>
            <b href="#a" tns:aX="yyy" />

            and the value of aX for b being "yyy" ?

            We would be placing a wide-ranging restriction just because there may be a small number of exceptions. I don't think we
            should be reading into the meaning of attributes which are not directly within the soap spec and, even then, we should
            use the same rules for these as for attributes outside the spec. It should be possible to parse the incoming message
            into an object model without reference to SOAP rules and then apply SOAP to the model. For this to work smoothly the
            rules for such things as attributes should be consistent and abstract (nothing specific for SOAP). SOAP rules can then
            be applied to the model.

            Currently we support multiple references to a value with the attribute lookups falling through. When a lookup is done on
            the attribute it is matched in the reference (accessor) first and if not found the lookup falls through to the
            underlying value. This is the same as merging the values.

            I understand the concern about something like xml:lang, but I don't think we should account for every case in the spec,
            but rather leave it up to the developer not to do things that don't make sense. Otherwise the spec is going to grow and
            grow!

            Pete
          • Noah_Mendelsohn@lotus.com
            +1 Ruling out cycles seems a mistake. Indeed, a main point of the chapter 5 serialization is allowing graphs of datastructures. Restricting that to acyclic
            Message 5 of 28 , Oct 12, 2001
            • 0 Attachment
              +1

              Ruling out cycles seems a mistake. Indeed, a main point of the chapter 5
              serialization is allowing graphs of datastructures. Restricting that to
              acyclic graphs seems like a mistake, and a significant limitation relative
              to SOAP 1.1.

              ------------------------------------------------------------------------
              Noah Mendelsohn Voice: 1-617-693-4036
              Lotus Development Corp. Fax: 1-617-693-8676
              One Rogers Street
              Cambridge, MA 02142
              ------------------------------------------------------------------------







              Robert van Engelen <engelen@...>
              10/12/2001 08:38 AM
              Please respond to soapbuilders


              To: soapbuilders@yahoogroups.com
              cc: (bcc: Noah Mendelsohn/CAM/Lotus)
              Subject: Re: [soapbuilders] What if multirefs were all inlined?



              > > Href before ID probably needn't be allowed, the encoding rules
              > > would have to state that there can be no forward references.
              >
              > It is currently permitted and so probably supported by most
              implementations. Even though the proposal is that multirefs
              > MAY be serialized inline, the current way of doing it is still valid.
              Currently a multirefs can come at the end of the

              I would like to add that in certain cases it is impossible to avoid
              forward
              references. For example, consider

              <ns:person id="1">
              <name>John</name>
              <address href="#2"/>
              </ns:person>
              <ns:address id="2">
              <street>Main</street>
              <city>Mytown</city>
              <livesAt href="#1"/>
              </ns:address>

              or

              <ns:struct>
              <part id="3">
              <name href="#4"/>
              </part>
              <product>
              <part href="#3"/>
              <name id="4">A</name>
              </product>
              </ns:struct>

              I am all for allowing embedded elements to be id'ed to support inline
              serialization of multirefs!

              > <a enc:position="[1]" id="c">string</a>
              > <b enc:position="[2]" href="#c" />

              With respect to earier discussions: I don't think there is a problem with
              this
              serialization as long as it is agreed upon that the href refers a *value*
              and
              not to the XML element with attributes and the value. So in this case,
              value
              "string" is placed at position="[2]". Should this convention be
              added/mentioned in the SOAP standard?

              - Regards, Robert



              -----------------------------------------------------------------
              This group is a forum for builders of SOAP implementations to discuss
              implementation and interoperability issues. Please stay on-topic.

              To unsubscribe from this group, send an email to:
              soapbuilders-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Glen Daniels
              +1 Forcing inline serialization, IMHO, is a bad idea. Allowing it seems like a good one. --Glen
              Message 6 of 28 , Oct 12, 2001
              • 0 Attachment
                +1

                Forcing inline serialization, IMHO, is a bad idea. Allowing it seems like a
                good one.

                --Glen

                > -----Original Message-----
                > From: Rich Salz [mailto:rsalz@...]
                > Sent: Friday, October 12, 2001 9:25 AM
                > To: Jacek Kopecky
                > Cc: soapbuilders@yahoogroups.com
                > Subject: Re: [soapbuilders] What if multirefs were all inlined?
                >
                >
                > Saying "you can inline at the first instance" is a small
                > simplification. Outlawing forward references is a big
                > limitation. For
                > example, it would make it impossible to add a XMLDSIG header element.
                > /r$
                > --
                > Zolera Systems, Securing web services (XML, SOAP, Signatures,
                > Encryption)
                > http://www.zolera.com
                >
                > -----------------------------------------------------------------
                > This group is a forum for builders of SOAP implementations to
                > discuss implementation and interoperability issues. Please
                > stay on-topic.
                >
                > To unsubscribe from this group, send an email to:
                > soapbuilders-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >
              • Paul Kulchenko
                Hi, Jacek! ... I don t think it s possible. cycles is just one of the examples of what won t be possible. Another one is below. I also understand that you re
                Message 7 of 28 , Oct 12, 2001
                • 0 Attachment
                  Hi, Jacek!

                  --- Jacek Kopecky <jacek@...> wrote:
                  > Href before ID probably needn't be allowed, the encoding rules
                  > would have to state that there can be no forward references. But
                  I don't think it's possible. cycles is just one of the examples of
                  what won't be possible. Another one is below. I also understand that
                  you're for "inline" encoding as only method for multiref encoding. I
                  don't see many benefits in just allowing for all data to be encoded
                  "inline".

                  > forward references could help solve your second problem - if the
                  > reference went from the header to the body and not the other way
                  > around (but this is a forward reference). I personally would
                  That's one of the options.

                  > 1) forbidding cross-linking between "serialization trees" and
                  > defining strict points where such "serialization trees" root;
                  Questionable

                  > 2) making referencing part of the core SOAP, on the same level
                  > as the processing model, and requiring that such cases be handled
                  > when removing the header etc. This would probably be helped by
                  > namespace-qualifying the href and id attributes. This would be
                  > very backwards-incompatible and the handling could be quite
                  > complex.
                  Complex to implement and will require to always (re)parse body when
                  you dealing with headers (even if you don't need to analize body).

                  > 3) ignore it.
                  ;) No, it won't work.

                  4) header references are always "forward" references. Doesn't help
                  with Header-Header reference.

                  5) (only) header-header or header-body references are encoded using
                  current method.

                  6) multirefs in headers are always encoded as single reference
                  (copy).

                  > The attribute clashes you show are actually not there if we
                  > clarify that, e.g. the attribute enc:position is on the
                  > "accessor" and not on the "data", so
                  > <a enc:position="[1]" id="c"/> <!-- accessor and data -->
                  > <b enc:position="[2]" href="#c"/> <!-- just an accessor -->
                  > And a reference href="#c" references the data, not the accessor.
                  Right, but I'm not telling that this is a problem, I'm just telling
                  that it's not clarified in proposal and needs to be addressed. At the
                  same time, I understand that attribute problem is orthogonal to
                  multiref encoding and can be specified for both types of encoding.

                  More on attribute in my other emails on this topic. Thanks, Jacek.

                  Best wishes, Paul.

                  __________________________________________________
                  Do You Yahoo!?
                  Make a great connection at Yahoo! Personals.
                  http://personals.yahoo.com
                • Paul Kulchenko
                  Hi, Robert! ... Absolutely agree. ... I don t think it s possible. It s reference to serialized data which is combination of value and attributes. My strong HO
                  Message 8 of 28 , Oct 12, 2001
                  • 0 Attachment
                    Hi, Robert!

                    --- Robert van Engelen <engelen@...> wrote:
                    > I would like to add that in certain cases it is impossible to avoid
                    > forward references. For example, consider
                    Absolutely agree.

                    > > <a enc:position="[1]" id="c">string</a>
                    > > <b enc:position="[2]" href="#c" />
                    > With respect to earier discussions: I don't think there is a
                    > problem with this
                    > serialization as long as it is agreed upon that the href refers a
                    > *value* and not to the XML element with attributes and the value.
                    I don't think it's possible. It's reference to serialized data which
                    is combination of value and attributes. My strong HO is datatype must
                    be specified on element with id and all attributes on href elements
                    must be ignored except several attrs that modify element's position
                    or role, as enc:position, env:actor, and env:mustunderstand.

                    I don't know whether you agree with [1], but imho nothing changed
                    with new rules, except that attributes allowed on HREF now also
                    allowed on elements with ID attribute.

                    How about this one:

                    <a foo="bar" id="a"/>
                    <b href="#a"/>

                    Where attribute foo="bar" belongs? only a? a and b? there was no
                    confusion with old (current) encoding: all attributes on ID belong to
                    all HREFs, all attributes on HREF element belong only to element
                    itself.

                    My take is simple: either a and b refer to precisely the same element
                    (only difference is 3 attributes mentioned above, but even actor and
                    mustUnderstand look strange in this context) and href element doesn't
                    have any attributes by itself (except possibly those three), or we
                    will discuss our interop problems for weeks (months?).

                    Best wishes, Paul.

                    [1] http://groups.yahoo.com/group/soapbuilders/message/5482

                    __________________________________________________
                    Do You Yahoo!?
                    Make a great connection at Yahoo! Personals.
                    http://personals.yahoo.com
                  • Paul Kulchenko
                    Hi, Jacek! ... It doesn t look like encoded multiref for me. As far as I understand we need multirefs to encode references to *the same object* that occur in
                    Message 9 of 28 , Oct 12, 2001
                    • 0 Attachment
                      Hi, Jacek!

                      --- Jacek Kopecky <jacek@...> wrote:
                      > <a id="c" xml:lang="en_us">hello</a>
                      > <b href="#c" xml:lang="de" />
                      > or even
                      > <a id="c" xsi:type="string">1234</a>
                      > <b href="#c" xsi:type="int" />
                      It doesn't look like encoded multiref for me. As far as I understand
                      we need multirefs to encode references to *the same object* that
                      occur in different places of tree. I can't come up with explanation
                      why they would have different attributes (except mentioned position,
                      actor and mustUnderstand). Am I missing something?

                      If it's just a case of XML reduction (as in case of xml:lang) it has
                      nothing to do with multirefs and shouldn't be mixed. imho

                      > So I'd rather go with listing the attributes allowable on
                      > referencing accesors, and the list would probably look like
                      > [href, enc:position].
                      I would add actor and mustUnderstand, because they have fixed
                      position regardless of used encoding method (forward or backward) and
                      can appear on both ID and HREF elements.

                      Best wishes, Paul.

                      __________________________________________________
                      Do You Yahoo!?
                      Make a great connection at Yahoo! Personals.
                      http://personals.yahoo.com
                    • Jacek Kopecky
                      Pete, please see my response below. Jacek Kopecky Idoox http://www.idoox.com/ ... The current SOAP encoding does not serialize any data into attributes. Any
                      Message 10 of 28 , Oct 15, 2001
                      • 0 Attachment
                        Pete, please see my response below.

                        Jacek Kopecky

                        Idoox
                        http://www.idoox.com/



                        On Fri, 12 Oct 2001, Pete Hendry wrote:

                        > > So I'd rather go with listing the attributes allowable on
                        > > referencing accesors, and the list would probably look like
                        > > [href, enc:position].
                        > >
                        >
                        > The problem is we can't predict what the developer wants
                        > and if we list the attributes which are *allowed* then we
                        > limit the developers scope. For example, I could define a
                        > complex type with attribute "aX". Why should the SOAP spec
                        > disallow me from saying
                        >
                        > <a id="a" tns:aX="xxx">string</a>
                        > <b href="#a" tns:aX="yyy" />
                        >
                        > and the value of aX for b being "yyy" ?

                        The current SOAP encoding does not serialize any data into
                        attributes. Any encoding using attributes is not SOAP encoding.
                        Multirefs are part of encoding. Therefore in your case you're
                        using different multiref mechanism from the one we're discussing
                        and you have to specify its rules yourself.

                        > We would be placing a wide-ranging restriction just because
                        > there may be a small number of exceptions. I don't think we
                        > should be reading into the meaning of attributes which are
                        > not directly within the soap spec and, even then, we should
                        > use the same rules for these as for attributes outside the
                        > spec. It should be possible to parse the incoming message
                        > into an object model without reference to SOAP rules and
                        > then apply SOAP to the model. For this to work smoothly the
                        > rules for such things as attributes should be consistent
                        > and abstract (nothing specific for SOAP). SOAP rules can
                        > then be applied to the model.

                        Pete, this is no problem at all: when you parse the XML to an
                        object model, you'll end up with a DOMish tree. Only when you
                        apply SOAP rules do you have multirefs.

                        > Currently we support multiple references to a value with
                        > the attribute lookups falling through. When a lookup is
                        > done on the attribute it is matched in the reference
                        > (accessor) first and if not found the lookup falls through
                        > to the underlying value. This is the same as merging the
                        > values.

                        As somebody pointed out in a mail probably after this your one,
                        multirefs are (or should be) meant as means of pointing to the
                        _same_ value, so any attributes that affect the value must be on
                        the id'd element. SOAP encoding only uses two other attributes,
                        that would be href and position. (please see my stand on actor
                        and mustunderstand in a subsequent email.)

                        > I understand the concern about something like xml:lang, but
                        > I don't think we should account for every case in the spec,
                        > but rather leave it up to the developer not to do things
                        > that don't make sense. Otherwise the spec is going to grow
                        > and grow!

                        But you have to show that there is a reasonable case unlike
                        xml:lang for which merging attributes is the way to go.

                        Regards, Jacek
                      • Jacek Kopecky
                        Paul, please see my response inside. 8-) Jacek Kopecky Idoox http://www.idoox.com/ ... I agree with you completely here. ... Here s where SOAP s layering shows
                        Message 11 of 28 , Oct 15, 2001
                        • 0 Attachment
                          Paul, please see my response inside. 8-)

                          Jacek Kopecky

                          Idoox
                          http://www.idoox.com/



                          On Fri, 12 Oct 2001, Paul Kulchenko wrote:

                          > > <a id="c" xml:lang="en_us">hello</a>
                          > > <b href="#c" xml:lang="de" />
                          > > or even
                          > > <a id="c" xsi:type="string">1234</a>
                          > > <b href="#c" xsi:type="int" />
                          > It doesn't look like encoded multiref for me. As far as I understand
                          > we need multirefs to encode references to *the same object* that
                          > occur in different places of tree. I can't come up with explanation
                          > why they would have different attributes (except mentioned position,
                          > actor and mustUnderstand). Am I missing something?
                          >
                          > If it's just a case of XML reduction (as in case of xml:lang) it has
                          > nothing to do with multirefs and shouldn't be mixed. imho

                          I agree with you completely here.

                          > > So I'd rather go with listing the attributes allowable on
                          > > referencing accesors, and the list would probably look like
                          > > [href, enc:position].
                          > I would add actor and mustUnderstand, because they have fixed
                          > position regardless of used encoding method (forward or backward) and
                          > can appear on both ID and HREF elements.

                          Here's where SOAP's layering shows the right way. There are two
                          layers here: 1) SOAP envelope with headers, 2) the data which
                          form a header.

                          Actor and mustUnderstand attributes are in the first layer and
                          they don't care what the data is. If the data is encoded using
                          SOAP encoding rules, this does in no way affect actor and
                          mustUnderstand. This means that these attributes must be on the
                          header, even if it is just
                          <ns:header href="#somethingelse"/>

                          The meaning of the attribute 'href' is hidden from the processor
                          when the layer-one-processing is being done. The values of actor
                          and mustUnderstand attributes, on the other hand, have no effect
                          on the actual header processor when the header is being
                          processed. And anyway, the processor should receive the header
                          (<ns:header href="#..."/>) and it can do whatever it will, e.g.
                          apply SOAP encoding rules to it. If it cares about actor and
                          mustUnderstand, it has to understand this layering.

                          So my response is: I don't think actor and mustUnderstand belong
                          to the list.

                          Regards,

                          Jacek
                        • Jacek Kopecky
                          Paul, please see my responses inside. This message contains a proposed solution to these problems, one that does not forbid forward linking, circular graph
                          Message 12 of 28 , Oct 15, 2001
                          • 0 Attachment
                            Paul, please see my responses inside.
                            This message contains a proposed solution to these problems, one
                            that does not forbid forward linking, circular graph data or
                            linking from a header to another. 8-)

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/



                            On Fri, 12 Oct 2001, Paul Kulchenko wrote:

                            > --- Jacek Kopecky <jacek@...> wrote:
                            > > Href before ID probably needn't be allowed, the encoding rules
                            > > would have to state that there can be no forward references. But
                            > I don't think it's possible. cycles is just one of the examples of
                            > what won't be possible. Another one is below. I also understand that
                            > you're for "inline" encoding as only method for multiref encoding. I
                            > don't see many benefits in just allowing for all data to be encoded
                            > "inline".

                            Cycles are not an example where you need forward references. If
                            you can inline the referenced data, you can serialize any graph
                            only using backward references (meaning backward in the XML
                            file):

                            <a id="a">
                            <b>
                            <c>
                            <a href="#a"/>
                            </c>
                            </b>
                            </a>

                            Yes, when dereferencing #a the parser doesn't have the full value
                            of #a yet, but this is a different problem and I don't want to
                            disallow this.

                            > > 1) forbidding cross-linking between "serialization trees" and
                            > > defining strict points where such "serialization trees" root;
                            > Questionable
                            >
                            > > 2) making referencing part of the core SOAP, on the same level
                            > > as the processing model, and requiring that such cases be handled
                            > > when removing the header etc. This would probably be helped by
                            > > namespace-qualifying the href and id attributes. This would be
                            > > very backwards-incompatible and the handling could be quite
                            > > complex.
                            > Complex to implement and will require to always (re)parse body when
                            > you dealing with headers (even if you don't need to analize body).

                            I agree. 8-)

                            > > 3) ignore it.
                            > ;) No, it won't work.
                            >
                            > 4) header references are always "forward" references. Doesn't help
                            > with Header-Header reference.
                            >
                            > 5) (only) header-header or header-body references are encoded using
                            > current method.
                            >
                            > 6) multirefs in headers are always encoded as single reference
                            > (copy).

                            What is the difference between headers and body? Your option #6
                            seems to be equivalent to my #1.

                            I think the only solutions that would work are my #1 and a
                            variation on your #5, because in your original #5 - what is the
                            top level of serialization again?

                            A possible solution (based on your #5, but enhanced):

                            ------- begin proposed text
                            Multireferences 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.
                            ------- end proposed text

                            (see the latest drafts for the 'none' actor definition.)

                            Rationale:

                            - Since headers are involved in such references, putting the
                            independent elements into the Header element is OK, it's already
                            there anyway. 8-)
                            - The actor 'none' will ensure that there can be no confusion
                            resulting from a node thinking it can understand a header that's
                            actually just an independent serialized data.


                            What do you all think?

                            Jacek
                          • Rich Salz
                            I don t like that user-data MUST appear in the header. For example, please write an XPATH expression that would capture all the data in such a case, so that I
                            Message 13 of 28 , Oct 15, 2001
                            • 0 Attachment
                              I don't like that user-data MUST appear in the header. For example,
                              please write an XPATH expression that would capture all the data in such
                              a case, so that I can do an XML DSIG of my application data.

                              Trailing elements seems much cleaner to me.

                              As for forward references, the first example that came to mind was a
                              doubly-linked list.
                              /r$
                              --
                              Zolera Systems, Your Key to Online Integrity
                              Securing Web services: XML, SOAP, Dig-sig, Encryption
                              http://www.zolera.com
                            • Jacek Kopecky
                              Rich, my wording allows for the user data to be all in the body. Just when the referenced data can be removed before removing all of the references to it, it
                              Message 14 of 28 , Oct 15, 2001
                              • 0 Attachment
                                Rich,
                                my wording allows for the user data to be all in the body. Just
                                when the referenced data can be removed before removing all of
                                the references to it, it must be in the header.
                                When the referenced data is in the body, it cannot be removed by
                                means of the usual SOAP processing, so it should be inlined -
                                exactly the thing you seem to want. 8-)
                                I'm not familiar with XPATH enough to know whether it is able to
                                handle dereferencing.
                                Trailing elements (after Body, inside the Envelope) are
                                forbidden now in the current drafts of the SOAP spec, but if this
                                is the best solution, I think they might be reintroduced. There
                                were some issues with handling of such trailers though which
                                might be bigger than the issues we have here. 8-)
                                And even double-linked list needn't be forward referenced:

                                <a id="1">
                                <value>1</value>
                                <prev id="2">
                                <value>4</value>
                                <prev id="3">
                                <value>3</value>
                                <prev id="4">
                                <value>2</value>
                                <prev href="#1"/>
                                <next href="#3"/>
                                </prev>
                                <next href="#2"/>
                                </prev>
                                <next href="#1"/>
                                </prev>
                                <next href="#4"/>
                                </a>

                                This is a double-linked, circular list of 1, 2, 3 and 4.
                                All the references point back. But I'm really not arguing that
                                forward references should go. 8-)

                                Best regards,

                                Jacek Kopecky

                                Idoox
                                http://www.idoox.com/



                                On Mon, 15 Oct 2001, Rich Salz wrote:

                                > I don't like that user-data MUST appear in the header. For example,
                                > please write an XPATH expression that would capture all the data in such
                                > a case, so that I can do an XML DSIG of my application data.
                                >
                                > Trailing elements seems much cleaner to me.
                                >
                                > As for forward references, the first example that came to mind was a
                                > doubly-linked list.
                                > /r$
                                >
                              • Robert van Engelen
                                Hi all, IMHO forward references should be allowed. It is true that inline serialization would solve the forward reference problem. However, SOAP must be kept
                                Message 15 of 28 , Oct 15, 2001
                                • 0 Attachment
                                  Hi all,

                                  IMHO forward references should be allowed. It is true that inline
                                  serialization would "solve" the forward reference problem.
                                  However, SOAP must be kept a symmetric protocol to make it easier to
                                  manipulate. Consider for example:

                                  <p>
                                  <name1 id="1">X</name1>
                                  <name2 href="#1"/>
                                  </p>

                                  Because the p's accessors can be reordered (i.e. complexType with "all" in the
                                  XML schema), this is semantically the same as

                                  <p>
                                  <name2 href="#1"/>
                                  <name1 id="1">X</name1>
                                  </p>

                                  IMHO to disallow forward references would artifically make SOAP a more strict
                                  protocol than necessary. It would be impossible to move parts of a payload
                                  around in the presence of forward pointers when SOAP actually allows
                                  reordering accessors in certain cases.

                                  Some tools (like mine) also rely on forward references.
                                  For example to serialize the following data:

                                  struct
                                  { int *p;
                                  int n;
                                  } x

                                  Setting the pointer x.p to point to x.n:

                                  x.p = &x.n

                                  This *should* be serialized with a forward reference to enable a receiver
                                  to deserialize this data without having to make a temporary copy.

                                  - Robert
                                • Paul Kulchenko
                                  Hi, Jacek! Thanks for your comments. My concerns and suggestions below ;) ... No, they are different. #1 describes serialization with two roots, and #6
                                  Message 16 of 28 , Oct 15, 2001
                                  • 0 Attachment
                                    Hi, Jacek!

                                    Thanks for your comments. My concerns and suggestions below ;)

                                    > > > 1) forbidding cross-linking between "serialization trees" and
                                    > > > defining strict points where such "serialization trees" root;
                                    > > 5) (only) header-header or header-body references are encoded
                                    > using current method.
                                    > >
                                    > > 6) multirefs in headers are always encoded as single reference
                                    > > (copy).
                                    >
                                    > What is the difference between headers and body? Your option #6
                                    > seems to be equivalent to my #1.

                                    No, they are different. #1 describes serialization with two roots,
                                    and #6 describes serialization of references between headers (or
                                    header-body) as references to distinct values. Current spec allows it
                                    and I don't see a reason why we shouldn't use it:

                                    [5.1] rules for serialization
                                    7. It is permissible to encode several references to a value as
                                    though these were references to several distinct values, but only
                                    when from context it is known that the meaning of the XML instance is
                                    unaltered.

                                    > I think the only solutions that would work are my #1 and a
                                    > variation on your #5, because in your original #5 - what is the
                                    > top level of serialization again?

                                    I didn't give any opinions and just described options we have ;). My
                                    choice is #6 :)

                                    > A possible solution (based on your #5, but enhanced):
                                    Your solution will definitely work. Here is the catch though: it
                                    introduces top level of serialization for Headers (bot not for Body),
                                    it uses one type of serialization for headers and another for body,
                                    and it uses header with ".../none" actor.

                                    My suggestion is simpler: any multirefs that involve different
                                    headers or header and body are serialized as distinct values. In this
                                    case it's just a question of clarification of current spec (which is
                                    vague on this aspect anyway). And it's still possible to have id/href
                                    inside serialization tree of one particular header, only
                                    crossreferences are serialized as "copies".

                                    Best wishes, Paul.

                                    --- Jacek Kopecky <jacek@...> wrote:
                                    > Paul, please see my responses inside.
                                    > This message contains a proposed solution to these problems, one
                                    > that does not forbid forward linking, circular graph data or
                                    > linking from a header to another. 8-)
                                    >
                                    > Jacek Kopecky
                                    >
                                    > Idoox
                                    > http://www.idoox.com/
                                    >
                                    >
                                    >
                                    > On Fri, 12 Oct 2001, Paul Kulchenko wrote:
                                    >
                                    > > --- Jacek Kopecky <jacek@...> wrote:
                                    > > > Href before ID probably needn't be allowed, the encoding
                                    > rules
                                    > > > would have to state that there can be no forward references.
                                    > But
                                    > > I don't think it's possible. cycles is just one of the examples
                                    > of
                                    > > what won't be possible. Another one is below. I also understand
                                    > that
                                    > > you're for "inline" encoding as only method for multiref
                                    > encoding. I
                                    > > don't see many benefits in just allowing for all data to be
                                    > encoded
                                    > > "inline".
                                    >
                                    > Cycles are not an example where you need forward references. If
                                    > you can inline the referenced data, you can serialize any graph
                                    > only using backward references (meaning backward in the XML
                                    > file):
                                    >
                                    > <a id="a">
                                    > <b>
                                    > <c>
                                    > <a href="#a"/>
                                    > </c>
                                    > </b>
                                    > </a>
                                    >
                                    > Yes, when dereferencing #a the parser doesn't have the full value
                                    > of #a yet, but this is a different problem and I don't want to
                                    > disallow this.
                                    >
                                    > > > 1) forbidding cross-linking between "serialization trees" and
                                    > > > defining strict points where such "serialization trees" root;
                                    > > Questionable
                                    > >
                                    > > > 2) making referencing part of the core SOAP, on the same
                                    > level
                                    > > > as the processing model, and requiring that such cases be
                                    > handled
                                    > > > when removing the header etc. This would probably be helped by
                                    > > > namespace-qualifying the href and id attributes. This would be
                                    > > > very backwards-incompatible and the handling could be quite
                                    > > > complex.
                                    > > Complex to implement and will require to always (re)parse body
                                    > when
                                    > > you dealing with headers (even if you don't need to analize
                                    > body).
                                    >
                                    > I agree. 8-)
                                    >
                                    > > > 3) ignore it.
                                    > > ;) No, it won't work.
                                    > >
                                    > > 4) header references are always "forward" references. Doesn't
                                    > help
                                    > > with Header-Header reference.
                                    > >
                                    > > 5) (only) header-header or header-body references are encoded
                                    > using
                                    > > current method.
                                    > >
                                    > > 6) multirefs in headers are always encoded as single reference
                                    > > (copy).
                                    >
                                    > What is the difference between headers and body? Your option #6
                                    > seems to be equivalent to my #1.
                                    >
                                    > I think the only solutions that would work are my #1 and a
                                    > variation on your #5, because in your original #5 - what is the
                                    > top level of serialization again?
                                    >
                                    > A possible solution (based on your #5, but enhanced):
                                    >
                                    > ------- begin proposed text
                                    > Multireferences 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.
                                    > ------- end proposed text
                                    >
                                    > (see the latest drafts for the 'none' actor definition.)
                                    >
                                    > Rationale:
                                    >
                                    > - Since headers are involved in such references, putting the
                                    > independent elements into the Header element is OK, it's already
                                    > there anyway. 8-)
                                    > - The actor 'none' will ensure that there can be no confusion
                                    > resulting from a node thinking it can understand a header that's
                                    > actually just an independent serialized data.
                                    >
                                    >
                                    > What do you all think?
                                    >
                                    > Jacek
                                    >
                                    >
                                    > ------------------------ Yahoo! Groups Sponsor
                                    >
                                    > -----------------------------------------------------------------
                                    > This group is a forum for builders of SOAP implementations to
                                    > discuss implementation and interoperability issues. Please stay
                                    > on-topic.
                                    >
                                    > To unsubscribe from this group, send an email to:
                                    > soapbuilders-unsubscribe@yahoogroups.com
                                    >
                                    >
                                    >
                                    > Your use of Yahoo! Groups is subject to
                                    > http://docs.yahoo.com/info/terms/
                                    >
                                    >


                                    __________________________________________________
                                    Do You Yahoo!?
                                    Make a great connection at Yahoo! Personals.
                                    http://personals.yahoo.com
                                  • Paul Kulchenko
                                    Hi, Jacek! ... I believe it s not very significant point, but my resolution from your arguments is actor and mustUnderstand attributes DO belong to the list
                                    Message 17 of 28 , Oct 15, 2001
                                    • 0 Attachment
                                      Hi, Jacek!

                                      > So my response is: I don't think actor and mustUnderstand belong
                                      > to the list.
                                      I believe it's not very significant point, but my resolution from
                                      your arguments is "actor and mustUnderstand attributes DO belong to
                                      the list" ;)). For me it's just a matter of specifying what
                                      attributes are allowed on what element. If you want to keep actor and
                                      mustUnderstand out of this, I wouldn't argue too much about it.
                                      Thanks.

                                      Best wishes, Paul.

                                      --- Jacek Kopecky <jacek@...> wrote:
                                      > Paul, please see my response inside. 8-)
                                      >
                                      > Jacek Kopecky
                                      >
                                      > Idoox
                                      > http://www.idoox.com/
                                      >
                                      >
                                      >
                                      > On Fri, 12 Oct 2001, Paul Kulchenko wrote:
                                      >
                                      > > > <a id="c" xml:lang="en_us">hello</a>
                                      > > > <b href="#c" xml:lang="de" />
                                      > > > or even
                                      > > > <a id="c" xsi:type="string">1234</a>
                                      > > > <b href="#c" xsi:type="int" />
                                      > > It doesn't look like encoded multiref for me. As far as I
                                      > understand
                                      > > we need multirefs to encode references to *the same object* that
                                      > > occur in different places of tree. I can't come up with
                                      > explanation
                                      > > why they would have different attributes (except mentioned
                                      > position,
                                      > > actor and mustUnderstand). Am I missing something?
                                      > >
                                      > > If it's just a case of XML reduction (as in case of xml:lang) it
                                      > has
                                      > > nothing to do with multirefs and shouldn't be mixed. imho
                                      >
                                      > I agree with you completely here.
                                      >
                                      > > > So I'd rather go with listing the attributes allowable on
                                      > > > referencing accesors, and the list would probably look like
                                      > > > [href, enc:position].
                                      > > I would add actor and mustUnderstand, because they have fixed
                                      > > position regardless of used encoding method (forward or
                                      > backward) and
                                      > > can appear on both ID and HREF elements.
                                      >
                                      > Here's where SOAP's layering shows the right way. There are two
                                      > layers here: 1) SOAP envelope with headers, 2) the data which
                                      > form a header.
                                      >
                                      > Actor and mustUnderstand attributes are in the first layer and
                                      > they don't care what the data is. If the data is encoded using
                                      > SOAP encoding rules, this does in no way affect actor and
                                      > mustUnderstand. This means that these attributes must be on the
                                      > header, even if it is just
                                      > <ns:header href="#somethingelse"/>
                                      >
                                      > The meaning of the attribute 'href' is hidden from the processor
                                      > when the layer-one-processing is being done. The values of actor
                                      > and mustUnderstand attributes, on the other hand, have no effect
                                      > on the actual header processor when the header is being
                                      > processed. And anyway, the processor should receive the header
                                      > (<ns:header href="#..."/>) and it can do whatever it will, e.g.
                                      > apply SOAP encoding rules to it. If it cares about actor and
                                      > mustUnderstand, it has to understand this layering.
                                      >
                                      > So my response is: I don't think actor and mustUnderstand belong
                                      > to the list.
                                      >
                                      > Regards,
                                      >
                                      > Jacek
                                      >
                                      >
                                      >
                                      > ------------------------ Yahoo! Groups Sponsor
                                      >
                                      > -----------------------------------------------------------------
                                      > This group is a forum for builders of SOAP implementations to
                                      > discuss implementation and interoperability issues. Please stay
                                      > on-topic.
                                      >
                                      > To unsubscribe from this group, send an email to:
                                      > soapbuilders-unsubscribe@yahoogroups.com
                                      >
                                      >
                                      >
                                      > Your use of Yahoo! Groups is subject to
                                      > http://docs.yahoo.com/info/terms/
                                      >
                                      >


                                      __________________________________________________
                                      Do You Yahoo!?
                                      Make a great connection at Yahoo! Personals.
                                      http://personals.yahoo.com
                                    • Jacek Kopecky
                                      Paul, in #6 you say no local references external to a header , whild in #1 I say no local references external to a serialization tree . We haven t defined
                                      Message 18 of 28 , Oct 15, 2001
                                      • 0 Attachment
                                        Paul, in #6 you say "no local references external to a header",
                                        whild in #1 I say "no local references external to a
                                        serialization tree". We haven't defined "serialization tree" yet,
                                        so why not define it as (single headers | whole Body)? 8-) #6 and
                                        #1 would be exactly the same. 8-)
                                        Anyway, in the scenario most often given for referencing from a
                                        header to a body, the XML digsig, you can't just copy the data,
                                        you have to actually reference it, because otherwise the copy is
                                        signed but nothing is there to ensure that the copies have
                                        remained the same.


                                        Jacek Kopecky

                                        Idoox
                                        http://www.idoox.com/



                                        On Mon, 15 Oct 2001, Paul Kulchenko wrote:

                                        > Hi, Jacek!
                                        >
                                        > Thanks for your comments. My concerns and suggestions below ;)
                                        >
                                        > > > > 1) forbidding cross-linking between "serialization trees" and
                                        > > > > defining strict points where such "serialization trees" root;
                                        > > > 5) (only) header-header or header-body references are encoded
                                        > > using current method.
                                        > > >
                                        > > > 6) multirefs in headers are always encoded as single reference
                                        > > > (copy).
                                        > >
                                        > > What is the difference between headers and body? Your option #6
                                        > > seems to be equivalent to my #1.
                                        >
                                        > No, they are different. #1 describes serialization with two roots,
                                        > and #6 describes serialization of references between headers (or
                                        > header-body) as references to distinct values. Current spec allows it
                                        > and I don't see a reason why we shouldn't use it:
                                        >
                                        > [5.1] rules for serialization
                                        > 7. It is permissible to encode several references to a value as
                                        > though these were references to several distinct values, but only
                                        > when from context it is known that the meaning of the XML instance is
                                        > unaltered.
                                        >
                                        > > I think the only solutions that would work are my #1 and a
                                        > > variation on your #5, because in your original #5 - what is the
                                        > > top level of serialization again?
                                        >
                                        > I didn't give any opinions and just described options we have ;). My
                                        > choice is #6 :)
                                        >
                                        > > A possible solution (based on your #5, but enhanced):
                                        > Your solution will definitely work. Here is the catch though: it
                                        > introduces top level of serialization for Headers (bot not for Body),
                                        > it uses one type of serialization for headers and another for body,
                                        > and it uses header with ".../none" actor.
                                        >
                                        > My suggestion is simpler: any multirefs that involve different
                                        > headers or header and body are serialized as distinct values. In this
                                        > case it's just a question of clarification of current spec (which is
                                        > vague on this aspect anyway). And it's still possible to have id/href
                                        > inside serialization tree of one particular header, only
                                        > crossreferences are serialized as "copies".
                                        >
                                        > Best wishes, Paul.
                                        >
                                        > --- Jacek Kopecky <jacek@...> wrote:
                                        > > Paul, please see my responses inside.
                                        > > This message contains a proposed solution to these problems, one
                                        > > that does not forbid forward linking, circular graph data or
                                        > > linking from a header to another. 8-)
                                        > >
                                        > > Jacek Kopecky
                                        > >
                                        > > Idoox
                                        > > http://www.idoox.com/
                                        > >
                                        > >
                                        > >
                                        > > On Fri, 12 Oct 2001, Paul Kulchenko wrote:
                                        > >
                                        > > > --- Jacek Kopecky <jacek@...> wrote:
                                        > > > > Href before ID probably needn't be allowed, the encoding
                                        > > rules
                                        > > > > would have to state that there can be no forward references.
                                        > > But
                                        > > > I don't think it's possible. cycles is just one of the examples
                                        > > of
                                        > > > what won't be possible. Another one is below. I also understand
                                        > > that
                                        > > > you're for "inline" encoding as only method for multiref
                                        > > encoding. I
                                        > > > don't see many benefits in just allowing for all data to be
                                        > > encoded
                                        > > > "inline".
                                        > >
                                        > > Cycles are not an example where you need forward references. If
                                        > > you can inline the referenced data, you can serialize any graph
                                        > > only using backward references (meaning backward in the XML
                                        > > file):
                                        > >
                                        > > <a id="a">
                                        > > <b>
                                        > > <c>
                                        > > <a href="#a"/>
                                        > > </c>
                                        > > </b>
                                        > > </a>
                                        > >
                                        > > Yes, when dereferencing #a the parser doesn't have the full value
                                        > > of #a yet, but this is a different problem and I don't want to
                                        > > disallow this.
                                        > >
                                        > > > > 1) forbidding cross-linking between "serialization trees" and
                                        > > > > defining strict points where such "serialization trees" root;
                                        > > > Questionable
                                        > > >
                                        > > > > 2) making referencing part of the core SOAP, on the same
                                        > > level
                                        > > > > as the processing model, and requiring that such cases be
                                        > > handled
                                        > > > > when removing the header etc. This would probably be helped by
                                        > > > > namespace-qualifying the href and id attributes. This would be
                                        > > > > very backwards-incompatible and the handling could be quite
                                        > > > > complex.
                                        > > > Complex to implement and will require to always (re)parse body
                                        > > when
                                        > > > you dealing with headers (even if you don't need to analize
                                        > > body).
                                        > >
                                        > > I agree. 8-)
                                        > >
                                        > > > > 3) ignore it.
                                        > > > ;) No, it won't work.
                                        > > >
                                        > > > 4) header references are always "forward" references. Doesn't
                                        > > help
                                        > > > with Header-Header reference.
                                        > > >
                                        > > > 5) (only) header-header or header-body references are encoded
                                        > > using
                                        > > > current method.
                                        > > >
                                        > > > 6) multirefs in headers are always encoded as single reference
                                        > > > (copy).
                                        > >
                                        > > What is the difference between headers and body? Your option #6
                                        > > seems to be equivalent to my #1.
                                        > >
                                        > > I think the only solutions that would work are my #1 and a
                                        > > variation on your #5, because in your original #5 - what is the
                                        > > top level of serialization again?
                                        > >
                                        > > A possible solution (based on your #5, but enhanced):
                                        > >
                                        > > ------- begin proposed text
                                        > > Multireferences 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.
                                        > > ------- end proposed text
                                        > >
                                        > > (see the latest drafts for the 'none' actor definition.)
                                        > >
                                        > > Rationale:
                                        > >
                                        > > - Since headers are involved in such references, putting the
                                        > > independent elements into the Header element is OK, it's already
                                        > > there anyway. 8-)
                                        > > - The actor 'none' will ensure that there can be no confusion
                                        > > resulting from a node thinking it can understand a header that's
                                        > > actually just an independent serialized data.
                                        > >
                                        > >
                                        > > What do you all think?
                                        > >
                                        > > Jacek
                                        > >
                                        > >
                                        > > ------------------------ Yahoo! Groups Sponsor
                                        > >
                                        > > -----------------------------------------------------------------
                                        > > This group is a forum for builders of SOAP implementations to
                                        > > discuss implementation and interoperability issues. Please stay
                                        > > on-topic.
                                        > >
                                        > > To unsubscribe from this group, send an email to:
                                        > > soapbuilders-unsubscribe@yahoogroups.com
                                        > >
                                        > >
                                        > >
                                        > > Your use of Yahoo! Groups is subject to
                                        > > http://docs.yahoo.com/info/terms/
                                        > >
                                        > >
                                        >
                                        >
                                        > __________________________________________________
                                        > Do You Yahoo!?
                                        > Make a great connection at Yahoo! Personals.
                                        > http://personals.yahoo.com
                                        >
                                        > -----------------------------------------------------------------
                                        > This group is a forum for builders of SOAP implementations to discuss implementation and interoperability issues. Please stay on-topic.
                                        >
                                        > To unsubscribe from this group, send an email to:
                                        > soapbuilders-unsubscribe@yahoogroups.com
                                        >
                                        >
                                        >
                                        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                        >
                                        >
                                      • Paul Kulchenko
                                        Hi, Jacek! ... I see now. I understood #1 as forbidding references between header and body (those are serialization trees we usually discuss ;)) and encode
                                        Message 19 of 28 , Oct 15, 2001
                                        • 0 Attachment
                                          Hi, Jacek!

                                          --- Jacek Kopecky <jacek@...> wrote:
                                          > Paul, in #6 you say "no local references external to a header",
                                          > whild in #1 I say "no local references external to a
                                          > serialization tree". We haven't defined "serialization tree" yet,
                                          > so why not define it as (single headers | whole Body)? 8-) #6 and
                                          > #1 would be exactly the same. 8-)
                                          I see now. I understood #1 as forbidding references between header
                                          and body (those are "serialization trees" we usually discuss ;)) and
                                          encode crossheaders references as immediate child of env:Header
                                          element (which is NOT what I'd like to have).

                                          > Anyway, in the scenario most often given for referencing from a
                                          > header to a body, the XML digsig, you can't just copy the data,
                                          > you have to actually reference it, because otherwise the copy is
                                          > signed but nothing is there to ensure that the copies have
                                          > remained the same.
                                          Absolutely! Sorry for confusion. All that I meant is that references
                                          between headers and from body to header are diallowed (serialized as
                                          distinct copies). References from header to body serialized in a
                                          usual way as you described.

                                          Best wishes, Paul.

                                          > On Mon, 15 Oct 2001, Paul Kulchenko wrote:
                                          >
                                          > > Hi, Jacek!
                                          > >
                                          > > Thanks for your comments. My concerns and suggestions below ;)
                                          > >
                                          > > > > > 1) forbidding cross-linking between "serialization
                                          > trees" and
                                          > > > > > defining strict points where such "serialization trees"
                                          > root;
                                          > > > > 5) (only) header-header or header-body references are
                                          > encoded
                                          > > > using current method.
                                          > > > >
                                          > > > > 6) multirefs in headers are always encoded as single
                                          > reference
                                          > > > > (copy).
                                          > > >
                                          > > > What is the difference between headers and body? Your option
                                          > #6
                                          > > > seems to be equivalent to my #1.
                                          > >
                                          > > No, they are different. #1 describes serialization with two
                                          > roots,
                                          > > and #6 describes serialization of references between headers (or
                                          > > header-body) as references to distinct values. Current spec
                                          > allows it
                                          > > and I don't see a reason why we shouldn't use it:
                                          > >
                                          > > [5.1] rules for serialization
                                          > > 7. It is permissible to encode several references to a value as
                                          > > though these were references to several distinct values, but
                                          > only
                                          > > when from context it is known that the meaning of the XML
                                          > instance is
                                          > > unaltered.
                                          > >
                                          > > > I think the only solutions that would work are my #1 and a
                                          > > > variation on your #5, because in your original #5 - what is
                                          > the
                                          > > > top level of serialization again?
                                          > >
                                          > > I didn't give any opinions and just described options we have
                                          > ;). My
                                          > > choice is #6 :)
                                          > >
                                          > > > A possible solution (based on your #5, but enhanced):
                                          > > Your solution will definitely work. Here is the catch though: it
                                          > > introduces top level of serialization for Headers (bot not for
                                          > Body),
                                          > > it uses one type of serialization for headers and another for
                                          > body,
                                          > > and it uses header with ".../none" actor.
                                          > >
                                          > > My suggestion is simpler: any multirefs that involve different
                                          > > headers or header and body are serialized as distinct values. In
                                          > this
                                          > > case it's just a question of clarification of current spec
                                          > (which is
                                          > > vague on this aspect anyway). And it's still possible to have
                                          > id/href
                                          > > inside serialization tree of one particular header, only
                                          > > crossreferences are serialized as "copies".
                                          > >
                                          > > Best wishes, Paul.
                                          > >
                                          > > --- Jacek Kopecky <jacek@...> wrote:
                                          > > > Paul, please see my responses inside.
                                          > > > This message contains a proposed solution to these problems,
                                          > one
                                          > > > that does not forbid forward linking, circular graph data or
                                          > > > linking from a header to another. 8-)
                                          > > >
                                          > > > Jacek Kopecky
                                          > > >
                                          > > > Idoox
                                          > > > http://www.idoox.com/
                                          > > >
                                          > > >
                                          > > >
                                          > > > On Fri, 12 Oct 2001, Paul Kulchenko wrote:
                                          > > >
                                          > > > > --- Jacek Kopecky <jacek@...> wrote:
                                          > > > > > Href before ID probably needn't be allowed, the encoding
                                          > > > rules
                                          > > > > > would have to state that there can be no forward
                                          > references.
                                          > > > But
                                          > > > > I don't think it's possible. cycles is just one of the
                                          > examples
                                          > > > of
                                          > > > > what won't be possible. Another one is below. I also
                                          > understand
                                          > > > that
                                          > > > > you're for "inline" encoding as only method for multiref
                                          > > > encoding. I
                                          > > > > don't see many benefits in just allowing for all data to be
                                          > > > encoded
                                          > > > > "inline".
                                          > > >
                                          > > > Cycles are not an example where you need forward references.
                                          > If
                                          > > > you can inline the referenced data, you can serialize any
                                          > graph
                                          > > > only using backward references (meaning backward in the XML
                                          > > > file):
                                          > > >
                                          > > > <a id="a">
                                          > > > <b>
                                          > > > <c>
                                          > > > <a href="#a"/>
                                          > > > </c>
                                          > > > </b>
                                          > > > </a>
                                          > > >
                                          > > > Yes, when dereferencing #a the parser doesn't have the full
                                          > value
                                          > > > of #a yet, but this is a different problem and I don't want to
                                          > > > disallow this.
                                          > > >
                                          > > > > > 1) forbidding cross-linking between "serialization
                                          > trees" and
                                          > > > > > defining strict points where such "serialization trees"
                                          > root;
                                          > > > > Questionable
                                          > > > >
                                          > > > > > 2) making referencing part of the core SOAP, on the same
                                          > > > level
                                          > > > > > as the processing model, and requiring that such cases be
                                          > > > handled
                                          > > > > > when removing the header etc. This would probably be
                                          > helped by
                                          > > > > > namespace-qualifying the href and id attributes. This
                                          > would be
                                          > > > > > very backwards-incompatible and the handling could be
                                          > quite
                                          > > > > > complex.
                                          > > > > Complex to implement and will require to always (re)parse
                                          > body
                                          > > > when
                                          > > > > you dealing with headers (even if you don't need to analize
                                          > > > body).
                                          > > >
                                          > > > I agree. 8-)
                                          > > >
                                          > > > > > 3) ignore it.
                                          > > > > ;) No, it won't work.
                                          > > > >
                                          > > > > 4) header references are always "forward" references.
                                          > Doesn't
                                          > > > help
                                          > > > > with Header-Header reference.
                                          > > > >
                                          > > > > 5) (only) header-header or header-body references are
                                          > encoded
                                          > > > using
                                          > > > > current method.
                                          > > > >
                                          > > > > 6) multirefs in headers are always encoded as single
                                          > reference
                                          > > > > (copy).
                                          > > >
                                          > > > What is the difference between headers and body? Your option
                                          > #6
                                          > > > seems to be equivalent to my #1.
                                          > > >
                                          > > > I think the only solutions that would work are my #1 and a
                                          > > > variation on your #5, because in your original #5 - what is
                                          > the
                                          > > > top level of serialization again?
                                          > > >
                                          > > > A possible solution (based on your #5, but enhanced):
                                          > > >
                                          > > > ------- begin proposed text
                                          > > > Multireferences 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.
                                          >
                                          === message truncated ===


                                          __________________________________________________
                                          Do You Yahoo!?
                                          Make a great connection at Yahoo! Personals.
                                          http://personals.yahoo.com
                                        Your message has been successfully submitted and would be delivered to recipients shortly.