[
Lists Home |
Date Index |
Thread Index
]
Hi Len
Len said:
> For those who don't follow markup history: automated
> typesetting systems drove markup to emerge as the
> progenitor of what we have today. The concept has
> been around for quite some time. The name belies the
> origin.
Didier replies:
And this is maybe why XML used to encode "rendering languages" is doing so
well. So if we recap we have
typesetting --> markup ---> SGML ---> XML
some further thoughts....
As you know, it also seems that we are surfing on "XML as an accepted
standard" to be used for other usages than rendering.
XML ----> rendering
|--------> data
|--------> procedure calls
XML used to encode data, to encode rendering objects, to encode procedure
calls. XML seems to evolve into a general "message encoding" medium.
We can also say that XML is slowly evolving into a framework. Part of this
framework is a good refined version of something more complex. In that sense
we reduced the complexity and came out with something more usable and
simpler. Thus, we applied the Occam razor and subscribed to the "less is
more" philosophy. Some other parts of this framework sit between two chairs,
suffers from an incomplete learning curve, or more simply suffers from the
"camel effect" [1]. For instance, if XML is used to encode data, why XLINK
is using a visual attribute to indicate if the referred document is to be
displayed or not. The whole notion of "display" refers to rendering
languages. Thus Xlink sits between two chairs.
To keep thing straight I would use the hierarchy mentioned previously as an
underlying thought structure when designing or modifying new XML framework
elements. however I would use the following order
1) data
2) procedure
3) rendering
Procedure is included here, not because I like it, simply as a matter of
fact, it is, for good or evil, part of our XML world. Thus, when designing a
part of the XML framework I would say:
a) it is a framework
b) is the basic tool we are adding or modifying do not mix data and
rendition. For instance, linking data do not imply that
we render it.
c) what is the intent of the new construct (render, structure data, call for
an action) and try not to be between two chairs and stick to one domain and
let other tools perform the transformation or resolve the impedence
mismatch.
d) Try as much as possible to remember that "less is more" and remember that
the fools that ignore history repeat the same mistakes. ADA or PL1 didn't
made it because they where to complex. C made it because it was simpler. In
one word: "focus".
I personally think that XML used to encode data as done by modern SQL DB or
XML native DB is a lot better than using XML as an RPC marshaling protocol.
But this is my taste and I am fully aware that a hammer cannot be used to
fix everything.
However, XML as used today to encode either a procedure call or data leads
to interesting side effects. And this particularity is brought by the XML
framework. We gained something new in the process. Let's take some seconds
of our time just to consider it.
data ---> rendering
or
procedure ---> rendering
For the last element, and because of the particular tools included in the
XML framework, we can say that a procedure could be either processed or
rendered. For instance, let's say that I have a SOAP call encoding the
following call:
post_transaction (string).
This latter expression could as well be encoded as a simple HTTP transaction
but, because the gorillas need us to depend on them[2], let's say that the
developer is forced to encode this as a SOAP call. Let's say that the
string contains an invoice which is an XML version of an EDI transaction. It
is so because of the hierarchical nature of XML and because the number of
lines in the invoice is variable. To encode the invoice as a structure is to
rigid (except if the notion of variant or union is supported) and this is
why we used a string to contain the XML document. This XML document could be
transformed with an XSLT style sheet and rendered.
Thus we have: procedure call ---> XSLT ---> rendering objects
This could be the case for a more rigid call like:
do_a_withdrawal (amount) - amount is a real number.
Again, if the call is encoded as a SOAP call, we can transform this
procedure call into a rendering object without any intervention from a
procedural construct. We gained something new with the XML framework: the
capacity to transform a data structure into an other or to render it without
any procedural code. We can also transform a SOAP document containing
several SOAP calls into data or into a rendering object[3]. Thus to
transform procedure calls into rendering objects without the intervention of
a procedural language.
again: procedure call ---> XSLT ---> rendering objects (no procedural code
in the process to resolve the impedence mismatch between rendering objects
and data contained in the procedure call and the rendering objects - This
implies that in the future I may have either a human being to perform the
procedure, hence having the procedure and data transformed into rendering
objects, or to get an automata to perfrom the action. The call would be same
for both - something like pay(invoice) - the automata may follow my rules
and pay the invoice automatically or I may get the invoice rendered and
manually pay it).
Off course the XML framework cannot resolve the independence mismatch with
all the legacy storage structures and this is why we still need procedural
constructs. Also the actual XML framework tools are insufficient for certain
tasks. However, we still have to explore a lot what we can do this
framework, and this is what I will do in Didier's labs. I'll keep you
informed.
cheers
Didier PH Martin
[1] you know the joke: a camel is a horse designed by a comity :-)
[2] This is the basic rule of monopoly: own all the lands and charge for it.
And if you own the lands, do not let them go :-)
[3] if we consider that a rendering object could contain other ones - hence
a hierarchy of rendering objects.
|
