MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ebxml-msg] Discussion: payload reference for use in SOAP body.Survey of options before writing this up.
So, something like the following may be a good idea..:
cid:<soapBody | attachmentID>[#XPath]
Producing the following valid URIs...
cid:attachment1
cid:attachment1#/ContainerElement/Invoice[0]
cid:soapBody
cid:soapBody#/Invoice[0]
The only problem I see is with namespaces and XPath. I'm not sure if there is an interoperable way to deal with XPath and namespaces. In the past, I've had to register prefix mappings with the XPath engine. Consider:
<SOAP:Body>
<Invoice xmlns="urn:typeA" />
<Invoice xmlns="urn:typeB" />
</SOAP:Body>
How do I point at a typeB invoice?
-matt
On May 20, 2004, at 12:44 PM, Dale Moberg wrote:
Using CID URL-References would have the advantage of being definite about which "document" is the one to look for the ID value.
That seems worth the added trouble. Supporting CIDs is something ebXML MSHes will have to do anyway when using sWa.
�
Also, having an "absolute" URI-Ref seems better than a "relative" one (which just means we create a problem of figuring out the base).
It means that "content-id" header must be used (which means the SOAP processor needs to�interact with�the MIME packager�and�coordinate�
the value for content-id).
�
The other question I have�is whether we should also allow some of the scheme-based pointers. That could have at least 2
advantages that I see:
�
1. We don't have to worry about using a schema to find out the ID type for attributes' values.
2. We wouldn't have to add attributes to elements just to pick out what is referred to.
�
A�disadvantage is�the added complexity of having another way to do something.
�
-----Original Message-----
From: Matthew MacKenzie [mailto:mattm@adobe.com]
Sent: Wednesday, May 19, 2004 4:44 PM
To: Dale Moberg
Subject: Re: [ebxml-msg] Discussion: payload reference for use in SOAP body. Survey of options before writing this up.
How about...
cid:soapBody#idval
<soap:Body>
������� <MyXML eb:cid="idval" />
</soap:Body>
Is it reasonable to expect nodes to be identified in such a way?
On May 19, 2004, at 7:19 PM, Dale Moberg wrote:
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.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/members/leave_workgroup.php.
___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
mattm@adobe.com
+1 (506) 871.5409
___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
mattm@adobe.com
+1 (506) 871.5409
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]