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

What if multirefs were all inlined?

Expand Messages
  • Jacek Kopecky
    Hello all. 8-) The W3C XML Protocol Working Group s Encoding task force is pondering now the issues of what s the top level of serialization and such and we
    Message 1 of 28 , Oct 11, 2001
    • 0 Attachment
      Hello all. 8-)
      The W3C XML Protocol Working Group's Encoding task force is
      pondering now the issues of "what's the top level of
      serialization" and such and we have a question for the SOAP
      builders community.
      In SOAP/1.1, referenced elements have to be "independent"
      elements at the top level of serialization, except for strings
      and byte arrays.
      What if the encoding rules were simplified to say that the
      multi-reference elements are in-line, they just contain the id
      attribute? Would this actually hurt anyone?
      Generating multiref data with the rules as they are now is
      sometimes painful as one has to put the XML representation of the
      data somewhere else than where it would be if it were referenced
      only once. Reading such data may be easier, except that for
      strings and byte arrays we have to search the whole serialization
      tree anyway. And the unclear term "top level of serialization"
      has caused a lot of interop trouble.
      What are the problems that you know you would encounter if the
      rules were simplified as above? Does anyone object to such a
      simplification?
      Best regards,

      Jacek Kopecky

      Idoox
      http://www.idoox.com/
    • Rich Salz
      +1 ! -- Zolera Systems, Your Key to Online Integrity Securing Web services: XML, SOAP, Dig-sig, Encryption http://www.zolera.com
      Message 2 of 28 , Oct 11, 2001
      • 0 Attachment
        +1 !
        --
        Zolera Systems, Your Key to Online Integrity
        Securing Web services: XML, SOAP, Dig-sig, Encryption
        http://www.zolera.com
      • Paul Kulchenko
        Hi, Jacek! ... It definitely won t hurt me, but there are still several questions to answer (hope you re not surprised ;) ). Is href before id allowed:
        Message 3 of 28 , Oct 11, 2001
        • 0 Attachment
          Hi, Jacek!

          > What if the encoding rules were simplified to say that the
          > multi-reference elements are in-line, they just contain the id
          > attribute? Would this actually hurt anyone?
          It definitely won't hurt me, but there are still several questions to
          answer (hope you're not surprised ;) ).

          Is href before id allowed: <a><b href="#c"/><c id="c"/></a> ?

          What to do with body/header element that refers to header element
          that was stripped out by intermediary?

          How to resolve attributes clash:

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

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

          I'm sure there are other questions that need to be answered.

          Best wishes, Paul.

          --- Jacek Kopecky <jacek@...> wrote:
          > Hello all. 8-)
          > The W3C XML Protocol Working Group's Encoding task force is
          > pondering now the issues of "what's the top level of
          > serialization" and such and we have a question for the SOAP
          > builders community.
          > In SOAP/1.1, referenced elements have to be "independent"
          > elements at the top level of serialization, except for strings
          > and byte arrays.
          > What if the encoding rules were simplified to say that the
          > multi-reference elements are in-line, they just contain the id
          > attribute? Would this actually hurt anyone?
          > Generating multiref data with the rules as they are now is
          > sometimes painful as one has to put the XML representation of the
          > data somewhere else than where it would be if it were referenced
          > only once. Reading such data may be easier, except that for
          > strings and byte arrays we have to search the whole serialization
          > tree anyway. And the unclear term "top level of serialization"
          > has caused a lot of interop trouble.
          > What are the problems that you know you would encounter if the
          > rules were simplified as above? Does anyone object to such a
          > simplification?
          > Best regards,
          >
          > Jacek Kopecky
          >
          > Idoox
          > http://www.idoox.com/
          >
          >
          >
          >
          > ------------------------ 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
        • Bob Cunnings
          Hello, I would welcome such a change. The bottom line is that it s painless from an implementation standpoint, since the support for inline multi-refs has to
          Message 4 of 28 , Oct 11, 2001
          • 0 Attachment
            Hello,

            I would welcome such a change.

            The bottom line is that it's painless from an implementation
            standpoint, since the support for "inline" multi-refs has to be there
            anyway, for the sake of strings and byte arrays.

            RC

            > Hello all. 8-)
            > The W3C XML Protocol Working Group's Encoding task force is
            > pondering now the issues of "what's the top level of
            > serialization" and such and we have a question for the SOAP
            > builders community.
            > In SOAP/1.1, referenced elements have to be "independent"
            > elements at the top level of serialization, except for strings
            > and byte arrays.
            > What if the encoding rules were simplified to say that the
            > multi-reference elements are in-line, they just contain the id
            > attribute? Would this actually hurt anyone?
            > Generating multiref data with the rules as they are now is
            > sometimes painful as one has to put the XML representation of the
            > data somewhere else than where it would be if it were referenced
            > only once. Reading such data may be easier, except that for
            > strings and byte arrays we have to search the whole serialization
            > tree anyway. And the unclear term "top level of serialization"
            > has caused a lot of interop trouble.
            > What are the problems that you know you would encounter if the
            > rules were simplified as above? Does anyone object to such a
            > simplification?
            > Best regards,
            >
            > Jacek Kopecky
            >
            > Idoox
            > http://www.idoox.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/
            >
          • Graham Glass
            I would personally welcome this! GLUE would encounter no problems. Cheers, graham ... From: Jacek Kopecky [mailto:jacek@idoox.com] Sent: Thursday, October 11,
            Message 5 of 28 , Oct 11, 2001
            • 0 Attachment

              I would personally welcome this!

              GLUE would encounter no problems.

               

              Cheers,

              graham

               

              -----Original Message-----
              From: Jacek Kopecky [mailto:jacek@...]
              Sent: Thursday, October 11, 2001 11:44 AM
              To: soapbuilders@yahoogroups.com
              Subject: [soapbuilders] What if multirefs were all inlined?

               

              Hello all. 8-)
              The W3C XML Protocol Working Group's Encoding task force is
              pondering now the issues of "what's the top level of
              serialization" and such and we have a question for the SOAP
              builders community.
              In SOAP/1.1, referenced elements have to be "independent"
              elements at the top level of serialization, except for strings
              and byte arrays.
              What if the encoding rules were simplified to say that the
              multi-reference elements are in-line, they just contain the id
              attribute? Would this actually hurt anyone?
              Generating multiref data with the rules as they are now is
              sometimes painful as one has to put the XML representation of the
              data somewhere else than where it would be if it were referenced
              only once. Reading such data may be easier, except that for
              strings and byte arrays we have to search the whole serialization
              tree anyway. And the unclear term "top level of serialization"
              has caused a lot of interop trouble.
              What are the problems that you know you would encounter if the
              rules were simplified as above? Does anyone object to such a
              simplification?
              Best regards,

                                          Jacek Kopecky

                                          Idoox
                                          http://www.idoox.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 the Yahoo! Terms of Service.
            • Bob Cunnings
              Hi Paul, Of course, these concerns must already exist for strings and byte arrays in the current spec, right? href before id is supported here for strings,
              Message 6 of 28 , Oct 11, 2001
              • 0 Attachment
                Hi Paul,

                Of course, these concerns must already exist for strings and byte
                arrays in the current spec, right?

                "href before id" is supported here for strings, etc. but I've never seen
                the second problem brought up before, at least not that I can recall.

                Hmmm.

                RC

                > Hi, Jacek!
                >
                > > What if the encoding rules were simplified to say that the
                > > multi-reference elements are in-line, they just contain the id
                > > attribute? Would this actually hurt anyone?
                > It definitely won't hurt me, but there are still several questions to
                > answer (hope you're not surprised ;) ).
                >
                > Is href before id allowed: <a><b href="#c"/><c id="c"/></a> ?
                >
                > What to do with body/header element that refers to header element
                > that was stripped out by intermediary?
                >
                > How to resolve attributes clash:
                >
                > now:
                > <a enc:position="[1]" href="#c"/>
                > <b enc:position="[2]" href="#c"/>
                > <c id="c"...../>
                >
                > then:
                > <a enc:position="[1]" id="c"/>
                > <b enc:position="[2]" href="#c"/>
                >
                > I'm sure there are other questions that need to be answered.
                >
                > Best wishes, Paul.
                >
                > --- Jacek Kopecky <jacek@...> wrote:
                > > Hello all. 8-)
                > > The W3C XML Protocol Working Group's Encoding task force is
                > > pondering now the issues of "what's the top level of
                > > serialization" and such and we have a question for the SOAP
                > > builders community.
                > > In SOAP/1.1, referenced elements have to be "independent"
                > > elements at the top level of serialization, except for strings
                > > and byte arrays.
                > > What if the encoding rules were simplified to say that the
                > > multi-reference elements are in-line, they just contain the id
                > > attribute? Would this actually hurt anyone?
                > > Generating multiref data with the rules as they are now is
                > > sometimes painful as one has to put the XML representation of the
                > > data somewhere else than where it would be if it were referenced
                > > only once. Reading such data may be easier, except that for
                > > strings and byte arrays we have to search the whole serialization
                > > tree anyway. And the unclear term "top level of serialization"
                > > has caused a lot of interop trouble.
                > > What are the problems that you know you would encounter if the
                > > rules were simplified as above? Does anyone object to such a
                > > simplification?
                > > Best regards,
                > >
                > > Jacek Kopecky
                > >
                > > Idoox
                > > http://www.idoox.com/
                > >
                > >
                > >
                > >
                > > ------------------------ 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 interope
                rability 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/
                >
              • Pete Hendry
                Definitely better than the current scheme. CapeConnect would not have a problem with this and I personally think it is the way to go. I would guess just about
                Message 7 of 28 , Oct 12, 2001
                • 0 Attachment
                  Definitely better than the current scheme. CapeConnect would not have a problem with this and I personally think it is
                  the way to go. I would guess just about everyone already supports it for reading.

                  The question of attribute clashes already exists with the current scheme so should not affect the decision below.

                  The more important question for this scheme is that of headers where the header contains the referenced value and the
                  header is stripped out. This is also already a problem when using String and byte[] which can be inline so it is again
                  outside the scope of this change since it already exists.

                  In summary, +1.

                  Pete

                  Jacek Kopecky wrote:
                  >
                  > Hello all. 8-)
                  > The W3C XML Protocol Working Group's Encoding task force is
                  > pondering now the issues of "what's the top level of
                  > serialization" and such and we have a question for the SOAP
                  > builders community.
                  > In SOAP/1.1, referenced elements have to be "independent"
                  > elements at the top level of serialization, except for strings
                  > and byte arrays.
                  > What if the encoding rules were simplified to say that the
                  > multi-reference elements are in-line, they just contain the id
                  > attribute? Would this actually hurt anyone?
                  > Generating multiref data with the rules as they are now is
                  > sometimes painful as one has to put the XML representation of the
                  > data somewhere else than where it would be if it were referenced
                  > only once. Reading such data may be easier, except that for
                  > strings and byte arrays we have to search the whole serialization
                  > tree anyway. And the unclear term "top level of serialization"
                  > has caused a lot of interop trouble.
                  > What are the problems that you know you would encounter if the
                  > rules were simplified as above? Does anyone object to such a
                  > simplification?
                  > Best regards,
                  >
                  > Jacek Kopecky
                  >
                  > Idoox
                  > http://www.idoox.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/
                • Jacek Kopecky
                  Paul, thank you for the very insightful response. 8-) I m not surprised by your questions and I ll gladly try to answer them. Href before ID probably needn t
                  Message 8 of 28 , Oct 12, 2001
                  • 0 Attachment
                    Paul, thank you for the very insightful response. 8-)
                    I'm not surprised by your questions and I'll gladly try to
                    answer them.

                    Href before ID probably needn't be allowed, the encoding rules
                    would have to state that there can be no forward references. But
                    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
                    allow forward references, but this of course depends on input of
                    others as well.

                    Cases like referencing data that can be stripped out of the
                    message on its path show an underlying deficiency which can be
                    solved in either of the following three ways:
                    1) forbidding cross-linking between "serialization trees" and
                    defining strict points where such "serialization trees" root;
                    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.
                    3) ignore it.
                    I suggest 1 or 3 even though 2 may be the cleanest. 8-)

                    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-)

                    I hope I've addressed all your concerns, let's discuss the three
                    options above to resolve which one the XMLP WG should pursue.


                    Jacek Kopecky

                    Idoox
                    http://www.idoox.com/



                    On Thu, 11 Oct 2001, Paul Kulchenko wrote:

                    > Hi, Jacek!
                    >
                    > > What if the encoding rules were simplified to say that the
                    > > multi-reference elements are in-line, they just contain the id
                    > > attribute? Would this actually hurt anyone?
                    > It definitely won't hurt me, but there are still several questions to
                    > answer (hope you're not surprised ;) ).
                    >
                    > Is href before id allowed: <a><b href="#c"/><c id="c"/></a> ?
                    >
                    > What to do with body/header element that refers to header element
                    > that was stripped out by intermediary?
                    >
                    > How to resolve attributes clash:
                    >
                    > now:
                    > <a enc:position="[1]" href="#c"/>
                    > <b enc:position="[2]" href="#c"/>
                    > <c id="c"...../>
                    >
                    > then:
                    > <a enc:position="[1]" id="c"/>
                    > <b enc:position="[2]" href="#c"/>
                    >
                    > I'm sure there are other questions that need to be answered.
                    >
                    > Best wishes, Paul.
                    >
                    > --- Jacek Kopecky <jacek@...> wrote:
                    > > Hello all. 8-)
                    > > The W3C XML Protocol Working Group's Encoding task force is
                    > > pondering now the issues of "what's the top level of
                    > > serialization" and such and we have a question for the SOAP
                    > > builders community.
                    > > In SOAP/1.1, referenced elements have to be "independent"
                    > > elements at the top level of serialization, except for strings
                    > > and byte arrays.
                    > > What if the encoding rules were simplified to say that the
                    > > multi-reference elements are in-line, they just contain the id
                    > > attribute? Would this actually hurt anyone?
                    > > Generating multiref data with the rules as they are now is
                    > > sometimes painful as one has to put the XML representation of the
                    > > data somewhere else than where it would be if it were referenced
                    > > only once. Reading such data may be easier, except that for
                    > > strings and byte arrays we have to search the whole serialization
                    > > tree anyway. And the unclear term "top level of serialization"
                    > > has caused a lot of interop trouble.
                    > > What are the problems that you know you would encounter if the
                    > > rules were simplified as above? Does anyone object to such a
                    > > simplification?
                    > > Best regards,
                    > >
                    > > Jacek Kopecky
                    > >
                    > > Idoox
                    > > http://www.idoox.com/
                    > >
                    > >
                    > >
                    > >
                    > > ------------------------ 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/
                    >
                    >
                  • Pete Hendry
                    ... It is currently permitted and so probably supported by most implementations. Even though the proposal is that multirefs MAY be serialized inline, the
                    Message 9 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
                      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
                    • 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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 27 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 28 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.