[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..., "Richard Anthony Hein" <935551@i...> wrote:
Hmm, I have to think about this - it's going to take a while.  
Hopefully
Kurt will jump in here, he's got the XSL/XSLT goods.

Richard
  -----Original Message-----
  From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
  Sent: July 6, 2000 10:02 AM
  To: xpl@e...
  Subject: Re: [XPL] Issue #2 - XPL will provide mechanisms to link 
XSL
documents to XML documents.


  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:
      a.. 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.

    a.. Message passing as text, usually via sockets.
    b.. 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!





----------------------------------------------------------------------
------
--



----------------------------------------------------------------------
------
--
  To unsubscribe from this group, send an email to:
  xpl-unsubscribe@o...
--- End forwarded message ---