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

Element name escaping

Expand Messages
  • Paul Kulchenko
    Hi, All! This question is already covered in XML Protocol issues, but there is no solution offered, so I would like to get opinions here. Problem: encoding of
    Message 1 of 11 , May 3, 2001
    • 0 Attachment
      Hi, All!

      This question is already covered in XML Protocol issues, but there is
      no solution offered, so I would like to get opinions here.

      Problem: encoding of element with illegal characters in the name ('a
      c', space between a and c)

      Possible solutions:
      1. specific type, like recently discussed Map.
      - specific for hash/map/struct encoding
      - didn't get much support
      + already implemented by ApacheSOAP and SOAP::Lite

      2. element escaping as in [1]. <a c> becomes <a_x0020_c>
      + works for all elements
      - list of issues [2]
      - doesn't supported by any SOAP toolkit

      3. name substitution. <a c> becomes <n1 realname="a c"> [3]
      + works for all elements
      + less number of issues than 2.
      - doesn't supported by any SOAP toolkit

      I personally like 2, but I couldn't find document Andrew mentioned in
      [1], and current webDAV specification doesn't have anything about
      character escaping (or I missed it there). So, what's everybody's
      opinion on encoding elements with illegal names?

      Best wishes, Paul.

      [1]
      http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=29921
      [2]
      http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=30851
      [3]
      http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=33153


      __________________________________________________
      Do You Yahoo!?
      Yahoo! Auctions - buy the things you want at great prices
      http://auctions.yahoo.com/
    • paulclinger@yahoo.com
      Hi, All! I hope previous message [1] was just lost in number if posts, because nobody responded and I can t believe that nobody cares. I would like to know
      Message 2 of 11 , May 17, 2001
      • 0 Attachment
        Hi, All!

        I hope previous message [1] was just lost in number if posts, because
        nobody responded and I can't believe that nobody cares. I would like
        to know other opinions on encoding elements with XML-invalid names.

        Best wishes, Paul.

        [1] http://groups.yahoo.com/group/soapbuilders/message/2909
      • grahamd@dscpl.com.au
        ... because ... like ... Can you post an actual example of what the XML looks like for the first case of using Map structure. Having trouble finding any
        Message 3 of 11 , May 18, 2001
        • 0 Attachment
          --- In soapbuilders@y..., paulclinger@y... wrote:
          > Hi, All!
          >
          > I hope previous message [1] was just lost in number if posts,
          because
          > nobody responded and I can't believe that nobody cares. I would
          like
          > to know other opinions on encoding elements with XML-invalid names.
          >
          > Best wishes, Paul.
          >
          > [1] http://groups.yahoo.com/group/soapbuilders/message/2909

          Can you post an actual example of what the XML looks like for the
          first case of using Map structure. Having trouble finding any
          documentation in SOAP-Lite or ApacheSoap which gives an example. I
          can't easily get SOAP-Lite to a state that it would run and have it
          produce output to look at and reading Perl code isn't something I am
          good at.

          The third case is basically the same thing I do now in an XML format
          I use in MOM style distributed messaging system and RPC over HTTP
          mechanism. Only difference is I use "name" instead of "realname". I
          have found in the past that using an attribute is the simplest way of
          doing it. You are limited to key being a string however.

          I too would like to see this issue discussed further, as without an
          accepted means of doing this, I can't put together a gateway for SOAP
          for the systems I have. If I just come up with my own way, chances
          are that nothing could then ever talk to it except clients I produce
          myself.

          BTW, the PythonWare SOAP library defines a type which is possibly
          similar to Map. Reading the code, they encode Python dictionaries as:

          <tag xsi:type='lab:PythonDict'>
          <k xsi:type="xsd:string">key1</k>
          <v xsi:type="xsd:int">1</k>
          <k xsi:type="xsd:string">key2</k>
          <v xsi:type="xsd:int">2</k>
          </tag>

          I believe they support any type as the key and not just string. This
          is more generic than using an attribute, as an attribute would only
          allow a string key.

          Does this Map type only allow string key or any type?
        • Rich Salz
          I much prefer an attribute. The problem is a general one: how do I encode a name that is not a valid XML element name ? It s a good problem. Defining a new
          Message 4 of 11 , May 18, 2001
          • 0 Attachment
            I much prefer an attribute. The problem is a general one: "how do I
            encode a name that is not a valid XML element name"? It's a good
            problem.

            Defining a new type is not a solution, because the name is independant
            of the type; I could have string whose name is "a c".

            Defining an encoding is not a solution, for two reasons. First, there
            is no way to tell that "a_x0020_c" is an encoded name, or not, which
            could cause a problem if I have a real name that looks like an encoded
            one. Second, there is no guarantee that the encoding method will always
            be appropriate, or even work. (E.g.., serializing a core dump where the
            "variables" are numeric memory locations. :)

            Therefore, I think the best approach is to define a new attribute used
            to indicate the real name. This attribute would include the encoding
            scheme as part of its semantics.

            This approach is also extensible because you could put more than one
            attribute, providing alternate names in diffferent encoding styles.

            And finally, channeling for Noah :), I can forward this to the dist-app
            list.
            /r$
          • Paul Kulchenko
            Hi, Graham! ...
            Message 5 of 11 , May 18, 2001
            • 0 Attachment
              Hi, Graham!

              > Can you post an actual example of what the XML looks like for the
              > first case of using Map structure. Having trouble finding any

              <?xml version="1.0" encoding="UTF-8"?>
              <SOAP-ENV:Envelope
              xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
              SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
              xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
              xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
              xmlns:xsd="http://www.w3.org/1999/XMLSchema"
              xmlns:xmlsoap="http://xml.apache.org/xml-soap">
              <SOAP-ENV:Body>
              <something>
              <map xsi:type="xmlsoap:Map">
              <item><key xsi:type="SOAP-ENC:base64">AAE=</key>
              <value xsi:type="xsd:int">456</value>
              </item>
              <item><key xsi:type="xsd:string">a</key>
              <value xsi:type="xsd:int">123</value>
              </item>
              </map>
              </something>
              </SOAP-ENV:Body></SOAP-ENV:Envelope>

              > can't easily get SOAP-Lite to a state that it would run and have it
              > produce output to look at and reading Perl code isn't something I
              > am good at.

              Here is the actual code you may use to produce Map:

              use SOAP::Lite;

              my $key = "\0\1";
              my $value = 456;

              print SOAP::Serializer->readable(1)->envelope(method =>
              something => SOAP::Data->name(map => {a => 123, $key => $value})
              );

              > I believe they support any type as the key and not just string.
              > This
              > is more generic than using an attribute, as an attribute would only
              > allow a string key.
              Looks very similar to what Map does.

              > Does this Map type only allow string key or any type?
              Any type. My example has binary string as the key, so it's encoded as
              base64.

              > mechanism. Only difference is I use "name" instead of "realname". I
              > have found in the past that using an attribute is the simplest way
              > of
              > doing it. You are limited to key being a string however.
              I agree. attributes has their own limitations, but it seems like most
              flexible solution. I would be glad to implement any of them, I just
              want to settle on something.

              Best wishes, Paul.

              --- grahamd@... wrote:
              > --- In soapbuilders@y..., paulclinger@y... wrote:
              > > Hi, All!
              > >
              > > I hope previous message [1] was just lost in number if posts,
              > because
              > > nobody responded and I can't believe that nobody cares. I would
              > like
              > > to know other opinions on encoding elements with XML-invalid
              > names.
              > >
              > > Best wishes, Paul.
              > >
              > > [1] http://groups.yahoo.com/group/soapbuilders/message/2909
              >
              > Can you post an actual example of what the XML looks like for the
              > first case of using Map structure. Having trouble finding any
              > documentation in SOAP-Lite or ApacheSoap which gives an example. I
              > can't easily get SOAP-Lite to a state that it would run and have it
              > produce output to look at and reading Perl code isn't something I
              > am
              > good at.
              >
              > The third case is basically the same thing I do now in an XML
              > format
              > I use in MOM style distributed messaging system and RPC over HTTP
              > mechanism. Only difference is I use "name" instead of "realname". I
              > have found in the past that using an attribute is the simplest way
              > of
              > doing it. You are limited to key being a string however.
              >
              > I too would like to see this issue discussed further, as without an
              >
              > accepted means of doing this, I can't put together a gateway for
              > SOAP
              > for the systems I have. If I just come up with my own way, chances
              > are that nothing could then ever talk to it except clients I
              > produce
              > myself.
              >
              > BTW, the PythonWare SOAP library defines a type which is possibly
              > similar to Map. Reading the code, they encode Python dictionaries
              > as:
              >
              > <tag xsi:type='lab:PythonDict'>
              > <k xsi:type="xsd:string">key1</k>
              > <v xsi:type="xsd:int">1</k>
              > <k xsi:type="xsd:string">key2</k>
              > <v xsi:type="xsd:int">2</k>
              > </tag>
              >
              > I believe they support any type as the key and not just string.
              > This
              > is more generic than using an attribute, as an attribute would only
              >
              > allow a string key.
              >
              > Does this Map type only allow string key or any type?
              >
              >
              >
              > 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!?
              Yahoo! Auctions - buy the things you want at great prices
              http://auctions.yahoo.com/
            • Andrew Layman
              The most thorough and current documentation of the algorithm for escaping element names is in this proposal to the SQL standards committee:
              Message 6 of 11 , Jun 5, 2001
              • 0 Attachment
                The most thorough and current documentation of the algorithm for
                escaping element names is in this proposal to the SQL standards
                committee:

                ftp://sqlstandards.org/SC32/WG3/Progression_Documents/WD/wd-xml-2001-05.
                pdf

                See sections 4.2.6, 5.1 and 5.4.

                -----Original Message-----
                From: Paul Kulchenko [mailto:paulclinger@...]
                Sent: Thursday, May 03, 2001 3:24 PM
                To: soapbuilders@yahoogroups.com
                Subject: [soapbuilders] Element name escaping


                Hi, All!

                This question is already covered in XML Protocol issues, but there is no
                solution offered, so I would like to get opinions here.

                Problem: encoding of element with illegal characters in the name ('a c',
                space between a and c)

                Possible solutions:
                1. specific type, like recently discussed Map.
                - specific for hash/map/struct encoding
                - didn't get much support
                + already implemented by ApacheSOAP and SOAP::Lite

                2. element escaping as in [1]. <a c> becomes <a_x0020_c>
                + works for all elements
                - list of issues [2]
                - doesn't supported by any SOAP toolkit

                3. name substitution. <a c> becomes <n1 realname="a c"> [3]
                + works for all elements
                + less number of issues than 2.
                - doesn't supported by any SOAP toolkit

                I personally like 2, but I couldn't find document Andrew mentioned in
                [1], and current webDAV specification doesn't have anything about
                character escaping (or I missed it there). So, what's everybody's
                opinion on encoding elements with illegal names?

                Best wishes, Paul.

                [1]
                http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=29921
                [2]
                http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=30851
                [3]
                http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=33153


                __________________________________________________
                Do You Yahoo!?
                Yahoo! Auctions - buy the things you want at great prices
                http://auctions.yahoo.com/

                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, Andrew! ... ftp://sqlstandards.org/SC32/WG3/Progression_Documents/WD/wd-xml-2001-05.pdf ... I think spec has a typo: 5.4 2) a) i) If i = 1 and X i+3 , X
                Message 7 of 11 , Jun 5, 2001
                • 0 Attachment
                  Hi, Andrew!

                  --- Andrew Layman <andrewl@...> wrote:
                  > The most thorough and current documentation of the algorithm for
                  > escaping element names is in this proposal to the SQL standards
                  > committee:
                  >
                  >
                  ftp://sqlstandards.org/SC32/WG3/Progression_Documents/WD/wd-xml-2001-05.pdf
                  >
                  > See sections 4.2.6, 5.1 and 5.4.
                  I think spec has a typo:

                  5.4 2) a) i) If i = 1 and X i+3 , X i+4 , X i+5 , and X i+6 are all
                  �F�, then let U 1 , U 2 , U 3 , U 4 , U 5 , U 6 , and U 7
                  be the zero-length string.

                  I believe it should be:

                  5.4 2) a) i) If i = 1 and X i+2 , X i+3 , X i+4 , and X i+5 are all
                  �F�, then let U 1 , U 2 , U 3 , U 4 , U 5 , U 6 , and U 7
                  be the zero-length string.

                  considering the context.

                  To advantage of this method, it can be implemented on top of existent
                  encoding, and since it basically ignores underscores ('_') if it
                  doesn't match pattern _xNNNN_ or _xNNNNNNNN_, there is no (big)
                  problem with backward compatibility.

                  What should be the next step? What should be the procedure in
                  general:
                  spec is published,
                  spec has an issue,
                  issue discussed and solutions are offered,
                  one solution is choosen,
                  ?
                  solution is implemented.

                  What should be in place of the question mark? New version of spec is
                  published? Some agreement is published? Comments are published? We
                  agree on soapbuilders list? At what point we can say: "ok, now let's
                  do it this way"? Thank you.

                  Best wishes, Paul.

                  > -----Original Message-----
                  > From: Paul Kulchenko [mailto:paulclinger@...]
                  > Sent: Thursday, May 03, 2001 3:24 PM
                  > To: soapbuilders@yahoogroups.com
                  > Subject: [soapbuilders] Element name escaping
                  >
                  >
                  > Hi, All!
                  >
                  > This question is already covered in XML Protocol issues, but there
                  > is no
                  > solution offered, so I would like to get opinions here.
                  >
                  > Problem: encoding of element with illegal characters in the name
                  > ('a c',
                  > space between a and c)
                  >
                  > Possible solutions:
                  > 1. specific type, like recently discussed Map.
                  > - specific for hash/map/struct encoding
                  > - didn't get much support
                  > + already implemented by ApacheSOAP and SOAP::Lite
                  >
                  > 2. element escaping as in [1]. <a c> becomes <a_x0020_c>
                  > + works for all elements
                  > - list of issues [2]
                  > - doesn't supported by any SOAP toolkit
                  >
                  > 3. name substitution. <a c> becomes <n1 realname="a c"> [3]
                  > + works for all elements
                  > + less number of issues than 2.
                  > - doesn't supported by any SOAP toolkit
                  >
                  > I personally like 2, but I couldn't find document Andrew mentioned
                  > in
                  > [1], and current webDAV specification doesn't have anything about
                  > character escaping (or I missed it there). So, what's everybody's
                  > opinion on encoding elements with illegal names?
                  >
                  > Best wishes, Paul.
                  >
                  > [1]
                  >
                  http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=29921
                  > [2]
                  >
                  http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=30851
                  > [3]
                  >
                  http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=33153
                  >
                  >
                  > __________________________________________________
                  > Do You Yahoo!?
                  > Yahoo! Auctions - buy the things you want at great prices
                  > http://auctions.yahoo.com/
                  >
                  > 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/
                  >
                  >
                  >
                  > 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!?
                  Get personalized email addresses from Yahoo! Mail - only $35
                  a year! http://personal.mail.yahoo.com/
                • Andrew Layman
                  You ask what the next steps should be. For the SQL Standards committee, of course, that is up to them. For us, I think we could agree to adopt the same
                  Message 8 of 11 , Jun 5, 2001
                  • 0 Attachment
                    You ask what the next steps should be. For the SQL Standards committee, of
                    course, that is up to them. For us, I think we could agree to adopt the
                    same convention.

                    ----- Original Message -----
                    From: "Paul Kulchenko" <paulclinger@...>
                    To: <soapbuilders@yahoogroups.com>
                    Cc: <xml-dist-app@...>
                    Sent: Tuesday, June 05, 2001 12:31 PM
                    Subject: RE: [soapbuilders] Element name escaping


                    Hi, Andrew!

                    --- Andrew Layman <andrewl@...> wrote:
                    > The most thorough and current documentation of the algorithm for
                    > escaping element names is in this proposal to the SQL standards
                    > committee:
                    >
                    >
                    ftp://sqlstandards.org/SC32/WG3/Progression_Documents/WD/wd-xml-2001-05.pdf
                    >
                    > See sections 4.2.6, 5.1 and 5.4.
                    I think spec has a typo:

                    5.4 2) a) i) If i = 1 and X i+3 , X i+4 , X i+5 , and X i+6 are all
                    'F', then let U 1 , U 2 , U 3 , U 4 , U 5 , U 6 , and U 7
                    be the zero-length string.

                    I believe it should be:

                    5.4 2) a) i) If i = 1 and X i+2 , X i+3 , X i+4 , and X i+5 are all
                    'F', then let U 1 , U 2 , U 3 , U 4 , U 5 , U 6 , and U 7
                    be the zero-length string.

                    considering the context.

                    To advantage of this method, it can be implemented on top of existent
                    encoding, and since it basically ignores underscores ('_') if it
                    doesn't match pattern _xNNNN_ or _xNNNNNNNN_, there is no (big)
                    problem with backward compatibility.

                    What should be the next step? What should be the procedure in
                    general:
                    spec is published,
                    spec has an issue,
                    issue discussed and solutions are offered,
                    one solution is choosen,
                    ?
                    solution is implemented.

                    What should be in place of the question mark? New version of spec is
                    published? Some agreement is published? Comments are published? We
                    agree on soapbuilders list? At what point we can say: "ok, now let's
                    do it this way"? Thank you.

                    Best wishes, Paul.

                    > -----Original Message-----
                    > From: Paul Kulchenko [mailto:paulclinger@...]
                    > Sent: Thursday, May 03, 2001 3:24 PM
                    > To: soapbuilders@yahoogroups.com
                    > Subject: [soapbuilders] Element name escaping
                    >
                    >
                    > Hi, All!
                    >
                    > This question is already covered in XML Protocol issues, but there
                    > is no
                    > solution offered, so I would like to get opinions here.
                    >
                    > Problem: encoding of element with illegal characters in the name
                    > ('a c',
                    > space between a and c)
                    >
                    > Possible solutions:
                    > 1. specific type, like recently discussed Map.
                    > - specific for hash/map/struct encoding
                    > - didn't get much support
                    > + already implemented by ApacheSOAP and SOAP::Lite
                    >
                    > 2. element escaping as in [1]. <a c> becomes <a_x0020_c>
                    > + works for all elements
                    > - list of issues [2]
                    > - doesn't supported by any SOAP toolkit
                    >
                    > 3. name substitution. <a c> becomes <n1 realname="a c"> [3]
                    > + works for all elements
                    > + less number of issues than 2.
                    > - doesn't supported by any SOAP toolkit
                    >
                    > I personally like 2, but I couldn't find document Andrew mentioned
                    > in
                    > [1], and current webDAV specification doesn't have anything about
                    > character escaping (or I missed it there). So, what's everybody's
                    > opinion on encoding elements with illegal names?
                    >
                    > Best wishes, Paul.
                    >
                    > [1]
                    >
                    http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=29921
                    > [2]
                    >
                    http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=30851
                    > [3]
                    >
                    http://discuss.develop.com/archives/wa.exe?A2=ind0005&L=soap&D=0&P=33153
                    >
                    >
                    > __________________________________________________
                    > Do You Yahoo!?
                    > Yahoo! Auctions - buy the things you want at great prices
                    > http://auctions.yahoo.com/
                    >
                    > 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/
                    >
                    >
                    >
                    > 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!?
                    Get personalized email addresses from Yahoo! Mail - only $35
                    a year! http://personal.mail.yahoo.com/

                    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/
                  Your message has been successfully submitted and would be delivered to recipients shortly.