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

Re: [soapbuilders] Support for Enumerations & QNames

Expand Messages
  • Bob Cunnings
    Hello, I ve been looking at QName myself, but it presents some headaches, as Rich points out. The element content can t simply be passed into the app as a
    Message 1 of 4 , Sep 5 11:08 PM
      Hello,

      I've been looking at QName myself, but it presents some headaches, as Rich
      points out. The element content can't simply be passed into the app as a
      string, of course.

      Presumably it could map to an internal representation consisting of:

      -- namespace URI
      -- local name
      -- (maybe) namespace prefix used

      All well and good, but at least in the implementation here, Section 5
      deserialization is a two step process. First the parse tree is built in
      response to SAX events. At this step the prefix/namespaceURI map is
      available for each element start, but the types of the elements are unknown
      (assuming that an xsi:type attribute isn't present). The data stored in each
      node is the raw element content. Secondly, the tree is traversed and the
      internal representation of the data in native format is formed. At this step
      the metadata is available so the types are known, and the element content
      strings can be converted to the native storage types. At this moment an
      particular element might be recognized as a "QName" type. If so, the element
      content could be parsed and the namespace prefix resolved to a namespace
      URI, with which to populate the object representing the QName. But no...
      unfortunately, the prefix/namespace map for that element is no longer
      available at this point.

      sigh.

      I suppose that each node in the parse tree could be endowed with a copy of
      the prefix/namespace map as it existed at the time of the node's creation,
      reflecting what namespace declarations were in scope for that element, but
      that seems expensive if needed only to support the QName type.

      Serialization is another issue, the local name would need to be prefixed,
      and a suitable namespace declaration stuffed into the opening tag of the
      element, to guarantee that it is in scope.

      Anyway, it's an interesting case, and I'm open to suggestions.

      RC

      > > I have a project where it would make sense to make use of Enums & QNames
      as
      > > parameters types, I was wondering how many toolkits have support for
      > > these types now ?
      >
      > ZSI supports enumerations for string, integer, and floating point (that
      > last is risky, of course :). By default I their type shows as string,
      > integer, etc., but it's easy for me to define new types.
      >
      > I've avoid QName, since the data is dependant, e.g., on the xmlns
      > attributes in the SOAP envelope (or wherever they happen to be). I
      > prefer using a sequence of anyuri,NCName
      > /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/
      >
      >
    • Simon Fell
      Yes, been down that road a couple of times already. FWIW, pocketSOAP folds those two steps into a single step that s done during parsing. [of course this makes
      Message 2 of 4 , Sep 5 11:41 PM
        Yes, been down that road a couple of times already. FWIW, pocketSOAP
        folds those two steps into a single step that's done during parsing.
        [of course this makes using the pocketSOAP engine as a server more of
        a challenge].

        My main concern at this point, it to ensure that the SOAP messages I'm
        defining can be implemented by a wide range of servers, its beginning
        to look like i'll use something else instead of QNames.

        Cheers
        Simon

        On Thu, 6 Sep 2001 00:08:58 -0600, in soap you wrote:

        >Hello,
        >
        >I've been looking at QName myself, but it presents some headaches, as Rich
        >points out. The element content can't simply be passed into the app as a
        >string, of course.
        >
        >Presumably it could map to an internal representation consisting of:
        >
        >-- namespace URI
        >-- local name
        >-- (maybe) namespace prefix used
        >
        >All well and good, but at least in the implementation here, Section 5
        >deserialization is a two step process. First the parse tree is built in
        >response to SAX events. At this step the prefix/namespaceURI map is
        >available for each element start, but the types of the elements are unknown
        >(assuming that an xsi:type attribute isn't present). The data stored in each
        >node is the raw element content. Secondly, the tree is traversed and the
        >internal representation of the data in native format is formed. At this step
        >the metadata is available so the types are known, and the element content
        >strings can be converted to the native storage types. At this moment an
        >particular element might be recognized as a "QName" type. If so, the element
        >content could be parsed and the namespace prefix resolved to a namespace
        >URI, with which to populate the object representing the QName. But no...
        >unfortunately, the prefix/namespace map for that element is no longer
        >available at this point.
        >
        >sigh.
        >
        >I suppose that each node in the parse tree could be endowed with a copy of
        >the prefix/namespace map as it existed at the time of the node's creation,
        >reflecting what namespace declarations were in scope for that element, but
        >that seems expensive if needed only to support the QName type.
        >
        >Serialization is another issue, the local name would need to be prefixed,
        >and a suitable namespace declaration stuffed into the opening tag of the
        >element, to guarantee that it is in scope.
        >
        >Anyway, it's an interesting case, and I'm open to suggestions.
        >
        >RC
        >
        >> > I have a project where it would make sense to make use of Enums & QNames
        >as
        >> > parameters types, I was wondering how many toolkits have support for
        >> > these types now ?
        >>
        >> ZSI supports enumerations for string, integer, and floating point (that
        >> last is risky, of course :). By default I their type shows as string,
        >> integer, etc., but it's easy for me to define new types.
        >>
        >> I've avoid QName, since the data is dependant, e.g., on the xmlns
        >> attributes in the SOAP envelope (or wherever they happen to be). I
        >> prefer using a sequence of anyuri,NCName
        >> /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/
        >>
        >>
        >
        >
        >
        >
        >-----------------------------------------------------------------
        >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/
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.