XSLT
processors seem to put quite different demands on the qualifications of names
and how XPath expressions
should
handle qualifiers. This in addition to the "xmlns"
attribute which simply can't be used like any other
attribute.
Using
the position of a Body child might work in some cases (although Invoice[1] below is probably better than Invoice[0]...)
but is
unsafe in others.
We
will face an increased interoperability threat posed by the reliance
of
payload processing utilities (introduced by new payload services, and
likely to be different from one MSH to the other).
Think
of the silent errors that could happen if an XPath expr just does not select the
payload part it should !
It may
be very difficult to detect this, and that would look bad if it needs the app
layer to be detected.
I
suspect the most practical way to deal with this is to think "testing mode",
i.e. an MSH should be able to process a message and its payloads just for trial,
and send back
a
notification containing a "trace" of the processing (which payload part has been
selected, and which utility has been applied, etc.) to the sender. This trace
could be automatically compared with a reference trace (either
given
by teh
sending party, or generated by Sender MSH over the same message, just to verify
that both MSH endpoints
would
behave similarly on the same message).
Jacques
-----Original Message-----
From: Matthew MacKenzie
[mailto:]
Sent: Thursday, May 20, 2004 8:55
AM
To: Dale Moberg
Cc:
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:]
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/
+1 (506) 871.5409
___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
+1 (506) 871.5409
