[exprla-devel] Re: [XPL] Issue #2 - XPL will provide mechanisms to link XSL documents to XML documents.

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Richard Anthony Hein wrote:

>
>
> Good questions.  This was a too-general statement I made.  The XSL
> specification states:
>
>      "XSL is a language for expressing stylesheets. Given a class
>      of arbitrarily structured XML [W3C XML] documents or data
>      files, designers use an XSL stylesheet to express their
>      intentions about how that structured content should be
>      presented; that is, how the source content should be styled,
>      laid out, and paginated onto some presentation medium, such
>      as a window in a Web browser or a hand-held device, or a set
>      of physical pages in a catalog, report, pamphlet, or book."
>
> I was thinking about this kind of output, so I was being far too
> general in stating the requirement.  However, now that I've thought
> about it more, perhaps XPL shouldn't touch on formatting the XML 
using
> stylesheets at all.  There probably isn't any point, except to say
> that XSL stylesheets can be called and linked to XML documents via
> XPL, in the same sense that ASP, VB or any other language link up 
XSL
> and XML documents now.  Other than that, XSL shouldn't effect our
> requirements.  If so, perhaps the requirement should read:
>
>    * XPL will provide mechanisms to link XSL documents to XML
>      documents.
>

In preparation for this, I've reviewed   the XSL specification , and 
the
answer to this is quite clear:

     XPL will include both the syntax and the semantics of XSL 
documents

Now recall that I'm recommending that all XSLT documents must be valid
XPL documents.

That's not quite as heavy a commitment as it might seem - XSLT 
documents
are in fact
XML with namespaces and with XPath patterns included as attributes of
template elements.
By requiring XPL to accept XSLT documents as citizens in good 
standing,
able to operate
on XML documents in conjuction with any new XPL processing we make up,
we are not
constraining XPL itself, as far as I can see.

If we broaden the requirement, from XSLT to XSL, we commit ourselves 
to
requiring XPL
to support (1) namespaces, (2) XSL-FO formatting objects, whatever 
these
turn out to be.

I don't think we can go any other way, without losing relevance to the
XML standards and
programming communities altogether.

This does not prevent us from defining subsets - "tiny XPL"s - as
namespaces which name
a smaller DTD with  limited element sets.

Nor does it exclude the possibilities that I think are worthwhile - 
the
explicit foundation in
Groves, the regexps and grammars - nor any other extensions, as long 
as
they are formatted
as XML-with-namespaces.

It does mean that any semantics we support must be compatible with the
semantics of
XSLT transformations and formatting objects. But that will not 
restrict
us, I'm almost
certain, if our semantics begins with Groves.

In sum, all of XSL must "just work" together with XPL.

XLST is already very powerful. It would certainly be possible to 
specify
a very classy XPL
indeed, just by using the provided extension elements. I am not
absolutely sure that those
will support the operations which we might want to bring in from other
programming languages,
though.  It is possible that we will choose to derive XPath and XLST
from something deeper,
i.e. Groves.

> Comments on this? So a new question arises from your questions
> Jonathan:  what shall we use to drive the range of output mechanisms
> in current use?  Your answer seems to be SOAP.  There is also
> XML-RPC.  Or will XPL have it's own version owing to the fact that
> grove property sets might be something to consider in this regard?
> There should probably be a new thread for this, like "output
> mechanisms".  But first let's state what the output mechanisms must
> accomplish.  Your turn!Richard Anthony Hein

I've had a rethink here. I suspect you were right the first time. XSL
may be all we need for
an output mechanism - provided we can stream it.

The reasoning is as follows. There appear to be only two basic
mechanisms for binding
 or translating between objects of different parentage.

   * Message passing as text, usually via sockets.
   * Procedure calls, remote or otherwise.

There are three major protocols extant, for publishing interfaces: 
COM,
CORBA and Java
Beans. They do the same job, it's just that there are slight 
differences
in the protocol,
the dialog, the handshaking, whatever we call it. They are all based 
on
procedure calls.
You can ask any object, of any of these families, to provide you with
its interface.
This gives you the means to call the methods of the object in 
question.

The alternative is message passing via text streams. For instance, 
HTML
has a built-in
channel to any local Javascript interpreter which might be resident 
in a
browser.
To exploit this mechanism, you only need to be able (1) to open a
channel,  (2) to
format the message text, and (3) to define a new tag in your system, 
to
indicate that
these are messages for the target system in question. Plus, the target
system needs
a procedure to call, to open the channel.

This doesn't seem hard to arrange. As a reality check, I have in mind
Mozilla's XUL,
which is an XML document type with a builti-in channel to Javascript. 
It
has an
impressively large manual, yes, but most of it seems to be concerned
with the
elements which correspond to the various Javascript operations and
objects it
binds to.

It's the other ones, the COM/CORBA/JBeans protocols, which present the
headache.
To talk to them, you need to be able to "marshal" the parameters for
every method
call, where the target object can get them when you make the call. I
don't know
the ins and outs of this at all well. I do know that it was hailed as
significant
progress last year, when some bright folks managed to get COM and 
CORBA
even talking to each other without restriction.

What I reckon, is that we should leave off specifying output 
processing,
at XSL.
This means that we are responsible for formatting the final output as
some XML
document type. E.g. the CORBA namespace or DTD. It will be up to the
programmers
of the target interface to provide a "hook", a little proxy object,
which can open
a channel for XPL to deliver the final XML output to, as text. A 
TCP/IP
service
port might do the trick. Once the channel is open, the hook object can
make and
receive whatever procedure calls it wants, to the target object. The
hook can
either swallow the XML output in one gulp, or stream it in.

This is handwavy, but it adds up to a policy we can stand by:

     XPL input and output will be in text form.

     Text forms output by XPL will be formatted via XSL.


Just as you said.

What about that implication that we're supporting multiple text 
streams
- one for
COM hooks, one for Javascript, etc etc? That's an exception to the 
rule,
but we
can get around it in practice - if we declare that there is a single
standard
text-stream-broker object, to which all external interpreters and 
hooks
can
couple. Once again, as a proof of concept, we could implement it as a
TCP/IP
service. It could use the same code as http, which is usually an
all-at-one-gulp
thing, but does support continuing channels.

Comments, please, from those wiser than I?


Jonathan

LOOK at the time! Oh, my fan, oh my gloves, the Duchess, the Duchess,
she'll have my head for sure!
--- End forwarded message ---