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

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

Expand Messages
  • Stefan Haustein
    ... In my opinion: *NO!!!* To me, it seems a good idea to design the attributes in a way that they are compliant with other XML standards, but without
    Message 1 of 41 , Dec 1, 2001
    • 0 Attachment
      Andrew Layman wrote:

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

      In my opinion: *NO!!!*

      To me, it seems a good idea to design the attributes in a
      way that they are compliant with other XML standards, but
      without requireing a SOAP implementation to understand all
      those standards.

      Please don't add more complexity, or let's go for a
      layered approach, similar to XHTLM vs. XHTML-Basic
      (for the same purpose). Perhaps a "Complex Remote
      Access Protocol" could be layered on top of SOAP
      (I replaced the O, too: I heard SOAP is not about
      objects anyway)?

      Best,
      Stefan
    • 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.