[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Discussion: payload reference for use in SOAP body. Survey of options before writing this up.
While CID-based URIs can work for picking out attachments for purposes of identifying them as operands for filtering services, the SOAP:body (or parts) was agreed to need some other reference notation. RFC 2396 -- http://www.ietf.org/rfc/rfc2396.txt URI Generic Syntax section 4.1 explains URI References and fragment identifiers URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ] The semantics of a fragment identifier is a property of the data resulting from a retrieval action, regardless of the type of URI used in the reference. Therefore, the format and interpretation of fragment identifiers is dependent on the media type [RFC2046] of theretrieval result. [Because CID could pick out any media type, there is apparently no uniform answer what a CID plus fragment identifier picks out. The CID apparently picks out the entire bodypart, headers included.] http://www.ietf.org/rfc/rfc3023 , which deals with XML Media types, including "text/xml" used for SOAP envelope, says about Fragment Identifiers Section 4.1 of [RFC2396] notes that the semantics of a fragment identifier (the part of a URI after a "#") is a property of the data resulting from a retrieval action, and that the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result. As of today, no established specifications define identifiers for XML media types. However, a working draft published by W3C, namely "XML Pointer Language (XPointer)", attempts to define fragment identifiers for text/xml and application/xml. The current specification for XPointer is available at http://www.w3.org/TR/xptr. The XML Pointer working draft, however, notes that it is superceded by: http://www.w3.org/TR/xptr-framework/ http://www.w3.org/TR/xptr-element/ http://www.w3.org/TR/xptr-xmlns/ http://www.w3.org/TR/xptr-xpointer/ The framework document is a recommendation This document is a Recommendation (REC) of the W3C. It has been reviewed by W3C Members and other interested parties and has been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web. and This document has been produced by the W3C XML Linking Working Group as part of the XML Activity. It is intended to address a core subset of the original XPointer requirements, and to serve, along with the accompanying XPointer element() Scheme and XPointer xmlns() Scheme specifications, as all or a foundational part of a fragment identifier syntax for the XML Media types. So, first point is that we should adopt the fragment identifer approach of http://www.w3.org/TR/xptr-framework/ IMO. Current simple fragment identifiers ( the "#frag" style) is discussed in the section on Shorthand Pointer: A shorthand pointer, formerly known as a barename, consists of an NCName alone. It identifies at most one element in the resource's information set; specifically, the first one (if any) in document order that has a matching NCName as an identifier. The identifiers of an element are determined as follows: If an element information item has an attribute information item among its [attributes] that is a schema-determined ID, then it is identified by the value of that attribute information item's [schema normalized value] property; If an element information item has an element information item among its [children] that is a schema-determined ID, then it is identified by the value of that element information item's [schema normalized value] property; If an element information item has an attribute information item among its [attributes] that is a DTD-determined ID, then it is identified by the value of that attribute information item's [normalized value] property. An element information item may also be identified by an externally-determined ID value. If no element information item is identified by a shorthand pointer's NCName, the pointer is in error. ==== So here is my question for the next call: is the shorthand pointer notation discussed above a good enough solution to the problem of identifying the part of the SOAP:body that is to be fed to a filter? [There is another option called the scheme-based pointer option that can also be used.] If so, then should we require absolute URI, relative URI, or omit the URI part? Go back to RFC 2396 -- http://www.ietf.org/rfc/rfc2396.txt sections 4.2 (Same Document Reference) and 5.* if you want to use relative. We will need to grapple with what the base URI is. If absolute, what URI should be used? I think I am leaning toward Shorthand and bare fragment identifier. Bare fragment identifier might be argued as ambiguous when using sWA because of possibility of the meaning of "the document" in section 4.2.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]