This paper describes Jamcracker’s position on the directions that the W3C should pursue to adequately formalize a processing model for XML. It describes the motivation for a formal processing model, and a particular history that led us to the current state. Then a list of potential requirements is given. A portion of a solution is proposed. Finally, a process for the W3C is proposed.
XML 1.0 specifies a simple processing model, well formedness then entity expansion and DTD validation. It contains a simple mechanism for informing processor of additional processing steps, the Processing Instruction. The XML related activities have created a number of new transformation technologies - Schema, XInclude, XSLT, XQuery, XML Base, XML Link — as well as technologies for addressing into XML documents - XPointer, XPath — and even messaging technologies — XMLP
What kind of problems does this cause?
The current XML and web service platform provides a complex workflow of tasks based upon the receipt of a web service request. We introduce straw-man web services architecture. The input is an XML document, perhaps encoded in XML Protocol. The runtime dispatcher, typically the first component to receive the request, will execute follow the following steps: 1) Validate request type information. 2) Dispatch to a transformation service. The transformation service can be implemented in a variety of languages, ranging from the W3C’s XSLT language to non-W3C languages such as Java, C#, Perl, etc. The transformation language interacts with databases and non-W3C applications. A typical example is a web service that interacts with SAP.
In addition, the W3C has currently chartered various committees to produce XML Encryption, XInclude, and XQuery specifications. Adding these specifications to the architecture, we see that the runtime dispatcher may execute the following steps, in an unspecified order:
There is a clear and obvious need for defining the various states and processes that the Web service request goes through. This is currently termed the XML Processing Model.
If we can specify an XML Processing model, then we have incrementally moved towards the vision that many early luminaries articulated. Reading Bush, Nelson, and other luminaries was a key motivation for me to join the Xlink Working Group. I am still trying to foster technologies to empower authors and clients to the level that Ted Nelson etc. talked about many years ago. A simple Use case is: Create a document that incorporates styled material from another document (say copyright notice). The XML Processing Model is another key step to make a reality out of the long ago visions.
There is an interesting dichotomy in the web today. The world of XML, XSLT, DTDs, XML Schema, Namespaces, is generally client-centric. To elaborate, it is anticipated that the document author specifies the schema, transformations, etc. The client trusts the author to create these. The client then does all the processing after retrieving the related documents. As an example of this, Xlink has the notion of Resources, and Arcs between these Resources. An application processing Xlinks is guided by “hints” on when and how to treat the linked resource. Interestingly, this is the first real break from a rigid processing model, and it occurred in the client-side view. The question of how to allow for optionality in the traversal/processing of nodes can cause interoperability problems.
In a directly related matter, one of the motivations for my proposals that begat XInclude was the lack of a rigid processing model for XLink. The desire to bring an inclusion processing model that is usable by any vocabulary naturally leads towards a desire to specify how inclusions and other processing mechanisms are usable by a variety of vocabularies.
In the world of Server APIs, many of the trust and reliability conditions of client-centric xml document retrieval are not true. In the Server API model, a client sends an xml document to a server. The server has already programmed what the schemas that it accepts are, the transformations that it will do. Indeed the server may only be an intermediary for the document. There is a contract in place.
Examining a server API model a little more closely, XMLP has the notion of processing steps through intermediaries: it can specify which node (Actor attribute) must understand particular headers (mustUnderstand attribute). A recent proposal introduced the notion of reporting results of header processing (hasHappened). There appear to be 2 use cases that XMLP supports. In the first model, a client creates an XMLP document and desires to rigidly specify the intermediaries and appropriate headers. In a second model, a client creates an XMLP document and only specifies the first intermediary or ultimate target. The client does not care about the intermediaries, simply the first or last end-point. These are fairly different models of processing.
Interestingly, XMLP is also introducing the notion of “hints” for node processing, to allow for a non-rigid processing model. I expect that XMLP hints will cause the same interoperability problems that hints in Xlink have caused. I believe that the general processing model should use as few hints as possible, preferably zero.
XMLP has not determined how to handle many headers in a given document. Imagine a scenario where a document has a SAML Authentication Assertion, an XML–DSig signature, a proxy header, a set of ebXML headers, and other headers. There is no mechanism even discussed for how to deal with profiles of headers. It is possible that a profile for client-centric document composition would be useful for server-centric header composition.
It is clear that there is potential overlap amongst an XML document processed by various xml document processor nodes, XMLP message routing through intermediary nodes, and Xlink traversal of resources nodes. I am unsure about the closeness of the graph traversal models. The emergence of “hints” in 2 disparate specifications indicates that there are probably underlying similarities. If they are fairly close, it seems probable a processing model activity could yield a re-usable syntax and processing model.
The following is a short and non-exhaustive list of problems that should be considered in scope for the processing model version 1.0
<mydoc xsi:schemaLocation="my.xsd"> <?xml-stylesheet href="my.xsl"?> <elem id="foo"/> </mydoc>
<mydoc xsi:schemaLocation="my.xsd"> <?xml-stylesheet href="my.xsl"?> <elem id="foo"/> <xi:include href="my2.xml"/> </mydoc>
http://dave/doc.xml. What is
http://dave/doc.xml#foo pointing to?
<soap:envelope xsi:schemaLocation="my.xsd"> <?xml-stylesheet href="my.xsl"?> <soap:header> <xi:include href="my2.xml"/> </soap:header> <elem id="foo"/> </soap:envelope>
A somewhat exhaustive list of potential processing model requirements is given below. I do not believe that they should all be addressed in version 1.0, but it should serve useful to determine scope for version 1.0
A number of difficult design questions emerge:
I offer a fragment of a proposal. The XML Processing model is an xml vocabulary, within or without a given xml document. It specifies the single order of processing steps in an imperative manner, without variable paths. The processing model author names the steps. XPointers can reference the document in these steps. A profile model is defined, where vocabularies can create a processing model specific to their vocabulary. These profiles are named and can be used as a reference to a processing model, rather than a by-value representation. The current specifications of XSLT and XML Schema have new syntaxes for expressing their processing instructions. This is a moderate number of new items,
Sample Syntax #1
<mydoc> <xmlp:header> <processing> <XInclude/> <xmlSchema href="my.xsd"/> <xslt href="my.xslt"/> </processing> </header> <xi:include href="my.xml#quote"/> </mydoc>
Sample syntax #2
<!-- include my.xml after my.xml been styled and after this doc
has been styled -->
<mydoc>
<xmlp:header >
<processing>
<XInclude/>
<xmlSchema href="my.xsd"/>
<xslt id="xslt1" href="my.xslt"/>
<xslt id="xslt2" href="my.xslt"/>
</processing>
</header>
<xi:include afterStep="xslt2" href="my.xml#xptr(xmlpm(afterstep=xslt), quote)"/>
</mydoc>
Sample syntax #3
<xmlp:header>
<processing>
<profile>
<type>W3C Document</type>
<date>2001-Jun</date>
</profile>
<!-- The notion of a "profile" of XML, in this case
all W3C XML recommendations related to documents as of June
2001. This is defined to be xml schema, xslt, namespaces,
but not XInclude -->
Sample syntax #4
<xmlp:header>
<processing>
<profile>
<type>SOAP 1.1</type>
<date>2001-Mar</type>
</profile>
<!-- The SOAP 1.1 profile indicates that SOAP intermediaries
are NOT to process any processing instructions. The
only processor of schemas, includes, etc. is at the
ultimate destination. -->
The processing model activity should be assigned to the Core Working Group. The Core WG has exposure to the issues through it’s work on XInclude. The Core WG will have time available, as it has successfully delivered infoset, xml errata, and XInclude. The Core WG has had experience in directly related areas, particularly infoset and XInclude. It has come to our attention that the W3C does not have many internal resources to contribute to efforts, such as the various proposals for web services related working groups. Tasking Core with xml processing means no further W3C resources need to be assigned. A secondary option is to disband the Core Working Group and create an XML Processing Model Working Group.
The charter of this group will be difficult to write. As always, a working group should err on the side of minimalism rather than maximalism scope. There are numerous dangerous scope areas, particularly the ideas of profiles, complex workflow languages, default orders, etc. I believe that members of a processing model work group will need to be very open about different approaches, but then soon determine a deliverable scope level.