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

Re: [soapbuilders] question re: use of "id" attributes in a SOAP envelope

Expand Messages
  • Andrew Layman
    No. You could only get away with duplicate id values if one of the portions of the document was neither marked with the SOAP encoding style nor validated by a
    Message 1 of 41 , Nov 30, 2001
    • 0 Attachment
      No. You could only get away with duplicate id values if one of the portions
      of the document was neither marked with the SOAP encoding style nor
      validated by a schema that declared the otherwise-conflicting attribute to
      be of type ID. The XML schema specification retains the XML constraint that
      attributes of type ID must have unique values across the entire document,
      not just across subtrees when validated independently. [1]

      As a practical matter, also, hrefs are going to often look like "#id123",
      which assumes a unique id value. The SOAP specification does not preclude
      more complex forms of reference, but deciding on which ones are available
      would be an interesting interoperability discussion. (Should all SOAP
      processors support XPath? XML Query? etc.)


      [1] http://www.w3.org/TR/xmlschema-2/#ID


      Andrew Layman
      http://strongbrains.com -- Resources for Self-Education
      ----- Original Message -----
      From: "Kirill Gavrylyuk" <kirillg@...>
      To: <soapbuilders@yahoogroups.com>
      Cc: <graham@...>
      Sent: Friday, November 30, 2001 12:33 PM
      Subject: RE: [soapbuilders] question re: use of "id" attributes in a SOAP
      envelope


      Thank you, Noah!
      So, I would think , as long as we don't put encodingStyle on Envelope, but
      put it separately on body level and on header level - Body and Header can be
      treated as encoded separately and we can have id attributes with the same
      values.

      It would be nice for processing on intermediary to allow not to care about
      the body content and process headers and body in orthogonal manner.

      What do you think?

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




      -----------------------------------------------------------------
      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/
    • Sam Ruby
      ... That takes care of the two easy examples. ... Perhaps you are being flip. Let s take a look at a harder example. What would be the natural mapping of
      Message 41 of 41 , Dec 3, 2001
      • 0 Attachment
        Noah Mendelsohn wrote:
        >
        > I believe that both of the examples you give are covered by the schema
        > data types spec (latest version at) [1], which is referenced normatively
        > by SOAP 1.1. Schemas is very clear that there is a distinction between
        > the lexical and the value space for a type. Although {01, and 1} are
        > different lexical representations, they represent the same value.

        That takes care of the two easy examples.

        > I agree that SOAP could be clearer that what is intended in the encoding
        > is the values. As a member of the schema WG, I can say that I've been
        > disappointed that we didn't do a better job of specifying the exact
        > mappings. Although it's clearly implied that lexical 321 has the decimal
        > value 321, I don't think we anywhere say that it's not 123 or 213 or even
        > 589.

        Perhaps you are being flip. Let's take a look at a harder example. What
        would be the "natural" mapping of "2.00" be into Java?

        Per http://jcp.org/aboutJava/communityprocess/first/jsr101/ , the mapping
        would be to BigDecimal.

        Per http://www.w3.org/TR/xmlschema-2/#decimal , the canonical
        representation in general prohibits trailing zeros. Specifically, the
        canonical representation for "2.00" is "2.0".

        Per,
        http://java.sun.com/j2se/1.3/docs/api/java/math/BigDecimal.html#equals(java.lang.Object)

        , scale is significant. Specifically, "2.00" is not equal to "2.0".

        = = = = =

        My takeaway from this discussion is that by clearly specifying that
        trailing zeros are to be ignored, the clear and natural mapping that a Java
        programmer would assume for decimals is explicitly prohibited. IMHO, that
        would be a pity.

        - Sam Ruby
      Your message has been successfully submitted and would be delivered to recipients shortly.