xml-dev - FW: About template. part 2

["Didier PH Martin" <martind@netfolder.com>]

Hi Don,

Don said:
-----------
Looks like we are heading toward same goal via different mental
track.  The word 'document' invokes too many preconceived notions
to be used in this context, I believe.  XML stream is more like it.
XML stream that changes its structure over time requires dynamic
schema with ability to redefine, augment, remove schema fragments.

Implementation wise, this is rather simple.  Have client dynamically
download schema fragment-specific handlers.  Security is no problem
since they are restricted to operations on the stream itself.  Java
is a perfect fit for this.

Didier reply:
-------------
Frankly I do not how to call this. Let's then look at it from a pragmatic
point of view and a "market observation" point of view (O yeah,
phenomenology again :-).

a) "market observation" point of view:
--------------------------------------
It seems that, in the last year, the tendency to use HTTP as a transport
mechanism and URLs as function call mechanism has gained some adepts. Take,
for example, the latest e-commerce specs from commerce.net (ref:
http://www.eco.commerce.net). An important trait of this latest spec is the
usage of URLs as function calls and XML as the result of these function
calls. The URL is divided with the following parts:
              <protocol>://<domain>/<function call>?<parameters>
The returned gizmo (replace gizmo with the term you find most appropriate)
is an XML text which does not contain a DTD and thus, no validation is
necessarily expected from the receiver.

We have here a classical request and response function. For Java people, it
is like doing a Java function call (having parameters) and obtain, as
result, a string containing an XML text.

If you take, this time, the Microsoft SQL technological preview. You can
observe that the same kind of mechanism is in place. a) a URL is used as a
function call with a SQL request as parameter. The URL is thus formatted as
follow:
            <protocol://<domain>/<virtual directory name>?sql=<SQL request>
The returned gizmo is also an XML text. Again for Java guys, its like doing
a function call with a SQL request as parameter and the function returns an
XML text contained in a string.

Oracle, on its side, supports URLs as function calls which refers to
specific XML gizmos containing SQL requests to be applied on a relational
database (not necessarily with the new SQL where the request may be applied
on an object view instead of a relational view). IN this last case, what is
very interesting though, is their notion of XML template. A whole XML gizmo
may be sent with a HTTP post to the server and this latter will return an
XML gizmo as request fulfillment.

I can go, on and on with some more examples, but three are probably enough.

>From these examples, we can deduct
1 - that HTTP is used as a transport mechanism. More particularly, two HTTP
verbs are mainly used: a) GET and b) POST. In both cases, and because of the
HTTP protocol requirements, a gizmo is returned and this gizmo has a MIME
type. In our case, the MIME type is "text/xml" (or an equivalent MIME type).
2 - The URL is used as a kind of function call. As we would find in any
function call having a sound constitution, it comes with parameters if there
is some needs for parameters.
3 - Basically what is returned is a model and more particularly a
hierarchical model encoded in an XML gizmo.

b) pragmatic point of view:
---------------------------
A workflow model as found in most workflow structures (ref:
http://www.wfmc.org/) is organized around a workflow engine. In a workflow,
a process is a succession of activities. The workflow engine has the
responsibility to "flow" the worked item from activity to activity. There is
different design choices that may be implemented for "task routing" like,
for instance, a) encoding the "route" in the item (which may be an XML
gizmo) b) keep this information internally hidden in the workflow engine. If
(a) is chosen and if XML is the format used to encode the gizmo that will be
moved from "task station" to "task station" then, each "task station" is
"carrying on" an activity to "transform" the XML gizmo or to extract
information (for purists, simply data :-) from the XML gizmo.

At each process stage, the XML gizmo may me stored and retrieved with the
HTTP protocol (respectively with the POST and GET verbs). Or may be  flowed
through the process with a mix of synchronous (i.e. HTTP) and asynchronous
(i.e. SMTP) transportation mechanisms.

The context being set, let's now get to the point.

If we take, for instance, biztalk, even if I have a fuzzy vision of what a
biztalk server will do, it remains that potentially a biztalk gizmo (i.e. an
XML gizmo) may contain "routing" information. Thus, the "routing" info is
stored in the document instead of being hidden in the workflow server. The
biztalk document or more particularly the "body" part may change in time as
each "task station" does its job. Thus, the biztak framework may be seen as
an envelope containing an XML gizmo that may change over time as "task
station" agent carry on their activity on this routed XML gizmo.

We can then see a biztalk envelope as the same kind of gizmo used in the
telecom industry to carry or transport data from one place to an other. For
instance, an IP packet can be contained in an Ethernet packet.

    	-----------------------------------------------------------------
	|Ethernet packet									|
	|											|
	|	-------------------------------------------------------	|
	|	| IP packet								|	|
	|	|									|	|
	|	-------------------------------------------------------	|
	|											|
	-------------------------------------------------------------------

I hope the mail won't scrap my pieces of arts :-))

As well, an e-commerce XML gizmo may be contained in a biztalk envelope.
This latter contains the "route" for the contained e-business XML gizmo.

    	-----------------------------------------------------------------
	|Biztalk envelope									|
	|											|
	|	-------------------------------------------------------	|
	|	| E-business XML gizmo						|	|
	|	|									|	|
	|	-------------------------------------------------------	|
	|											|
	-------------------------------------------------------------------

I picked here biztalk, not because I am a Microsoft fan, but simply because
its out there and documented and probably will have a certain influence in
the community (I agree Len, the balance of power is not yet in the hands of
the knowledge but still in the hands of the capital :-) ref: The post
industrial society by Daniel Bell).

Thus, we have here a potential network of HTTP servers, used to route
particular XML gizmos from task station to task stations where activities
carried on this XML gizmo conduct to its transformation (i.e. the biztalk
body) or get data extracted from the xml Gizmo.

Lesson learned from this:
------------------------------------
1 - These kind of HTTP servers are then special kind of XML servers used to
route XML gizmos. Other kind of XML task station carry on acivity on the XML
gizmo.
2 - Some XML elements are used as "routing" information containers for "task
stations". Thus, the XML gizmo is a particular assembly composed of one part
used for transportation and "task routing", an other part being the
meaningful gizmo transported. Both parts may change in time. For instance,
the routing part may loose all previous "routing" locations as it moves
through the process. The other XML gizmo part may change as "task agents"
modify it along the way.
3 - The basic interaction between all the agents is conducted through HTTP
basic verbs POST and GET and thus is based on a simple request response
system. However, other transportation means may be used as for instance the
mail (SMTP protocol) to move th XML gizmo from a routing server to an other
and to and from this server and a task station. Thus, HTTP is not the only
mean of transportation but seems to be an important one.
4 - The contained gizmo may include a special PI for rendition and then
could be first, extracted from the transport XML gizmo and then rendered
with any XML browsers equipped with the proper rendition engine (for example
CSS or XSLT-HTML/CSS). This may be required as the "task agent" may be a
human being having to do task where visual (or should I said here sensorial)
examination leads to an action taken on or from this rendered XML gizmo.

So, if what is transported by HTTP or SMTP is a document or not, I do not
know, so let's call it an XML gizmo :-)

Simple Saturday morning reflections
Cheers
Didier PH Martin
mailto:martind@netfolder.com
http://www.netfolder.com



xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)