[exprla-devel] Re: [XPL] Re: a domain name for XPL

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

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

>
>
>   1. XPL will stream XML data, in an asynchronous and/or synchronous
>      format, and support multiple streams of heterogeneous data,
>      including non-XML media types.
>

I support this as a requirement, except that I'm not sure what
"synchronous" and "asynchronous"
mean in context here.

From my simple hardware background, "synchronous" means: multiple
processes are going on;
their outputs must be combined, and delivered in a correct order; to
ensure this, processes are
constrained to open for input or output only on logical conditions,
which are dependent on a
global counter or timestamping system.

Is this the sense of things for Web protocols?  Lucas? Kurt?

>   1. XPL will format output using XSL.
>

I don't know about this. Is XSL diverse enough to drive the range of
output mechanisms
in current use? Can it efficiently make method calls to COM objects?
Talk to Java Beans?
Generate Perl, or Postscript?

I mean, it was beginning to sound to me that SOAP would make the right
kind of output
stage for most purposes.

>   1. XPL will transform XML data using XSLT.
>

No.

I want a weaker requirement than that.  Say,

"All XSLT transformations will be valid XPL operations."

From what I've seen so far, and I emphasize that I've seen a lot more
trees than forests,
I can accept Groves as The inclusive foundation for XPL - but XSLT 
only
as a standard
XPL subset, possibly one among many.

Because my impression is, that the XSLT people spend a lot of time
working out how
to make it serve fairly simple ends. It's not just that the XML syntax
is unwieldly,
it's that they can't work out how the pieces fit together.

What I want, and I'll canvas it as a requirement, is:

"XPL operations will be derived from a simple and comprehensible set 
of
basic principles."

What might the basics be? I'm not completely sure, but here are the 
ones
I'd bet on, currently:

   * Recursion.
   * Uniform definition of node structure - i.e. architectural forms.
   * Recursion in node connectivity definitions - i..e. groves &
     hypergroves.
   * Regular expressions (regexps) , for text parsing.
   * Regular languages (grammars), for document type definition.
   * Document types as first-class objects.
   * Execution by means of pattern (i.e. regexp) recognition and
     substitution.
   * Easy use of divide-and-conquer algorithms.
   * Object-oriented programming.

Each of these has either, an inherent simplicity, or a coherent
theoretical basis.

Except maybe for OOP, but OOP includes important principles of
distinction
such as encapsulation, which help avoid inappropriate couplings.


Obviously, I'll need to explain some of these principles really soon. 
I
was hoping for
more time, to do a compare-and-contrast between XSLT and several other
widespread
tree-structured programming-language paradigms, before I opened my 
yap.
Going into
them right now means setting aside the first JDK I've ever used, 
before
I've had any
hands-on with XML at all.

I'll back up and do it if need be - but I think it's premature. I 
really
have to mobilize
the XML/XSL machinery, and run a few stylesheets of a few documents,
before I
can seriously judge the worth of XSLT.


>   1. XPL will be optimized to operate on a peer-to-peer network,
>      however client-server models and offline computing will also be
>      supported fully.
>

Lucas Gonze is the one to ask about this.

Lucas, what features in an XML-processing system (think of this as
pipelining
XLST transformations) would make it most suitable for efficient use 
of a

peer-to-peer protocol such as WorldOS?

>   1. XPL will use agents, among other methods to operate on XML.
>

I agree - at least so far as I understand agents. We're talking about
XPL documents,
i.e. programs, which wander about in the fog, processing public
documents and
dispatching the results to their owners or to public collections - am 
I
right?

>   1. XPL will use RDF to locate resources.
>

This sounds right. RDF is a siteless, content-addrssed structure, if I
recall.

But, and I hate to say this, RDF is one more semi-standard for me to
study up -
and compare with Linda, which sounds similar - before I can pronounce.

>   1. XPL will use XLink to create, follow, and generate links 
between
>      resources.
>
>   1. XPL will use XPath as the language to describe resource
>      locations.
>

Same qualms as with XSLT.

>   1. XPL will be an interface-based object-oriented language, and 
the
>      interfaces will be exposed as XML 1.0 compliant XML (although 
the
>      programs themselves may or may not be).
>

I'm sure this is right.

>   1. XPL will NEVER support APIs that are not FULLY opensource and
>      public domain, as closed source APIs may fork XPL.
>

Rather than "never support", I would like to require "never be 
dependent
on".

If XPL turns out to be really useful, private outfits will define
support in it for their
own APIs, and the specification will fork.

>   1. Anyone MAY create private APIs, however, they MAY NOT publish 
or
>      redistribute said APIs outside of private or corporate usage,
>      unless first reviewed, accepted, integrated (into the XPL API
>      library) and simultaneously published by the XPL working group.
>      Upon such an event, the API also becomes opensource and public
>      domain under the license terms which XPL operates under (yet to
>      be decided).
>

I don't see that we have the right to require this of anyone, or the
ability to enforce it.
As an analogy, does W3C have any right to prevent, say Allaire from
reproducing
XSLT as a feature of Cold Fusion?

I certainly understand the intention to reject any engulf-and-extend
monkey business
on the part of private corps. I'm just not sure that we can.

> There's ten.  They are simple, and say at least a few things that 
XPL
> will do.  Comments?  Number 10 is a tricky one. Richard A. Hein

Sorry if I seem balky on some of these. They are the right questions 
to
ask,
it's just that I plain don't know some of the answers.

Back soon

Jonathan
--- End forwarded message ---