MHonArc v2.5.0b2 -->
ebxml-msg message
[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]