ebxml-msg message

Subject: RE: [ebxml-msg] Discussion: payload reference for use in SOAP body. Survey of options before writing this up.

From: Jacques Durand <JDurand@us.fujitsu.com>
To: "'Matthew MacKenzie'" <mattm@adobe.com>, Dale Moberg <dmoberg@cyclonecommerce.com>
Date: Thu, 20 May 2004 12:57:04 -0700

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:mattm@adobe.com]
Sent: Thursday, May 20, 2004 8:55 AM
To: Dale Moberg
Cc: ebxml-msg@lists.oasis-open.org
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