exprla-devel — This is the Developers' list for the for XPL

[exprla-devel] New Newsgroup: comp.text.xml.xpl

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

--- In xpl-dev@y..., cagle@o... wrote:
I've set up an interim newsgroup on my own server for dealing with 
XPL issues. This isn't public yet, though I'd like to eventually 
migrate it there once we reach a critical mass.  The location is

news://208.1.204.8/comp.text.xml.xpl  

Feel free to pass the full URL to other people you feel may be 
interested in XPLs. This is also meant primarily as an adjunct to the 
mailing group list -- ultimately, I plan to archive the newsgroup 
material when we get the site up and running.

-- Kurt Cagle
--- End forwarded message ---

[exprla-devel] Re: [XPL] - WorldOS - framework for distributed computing

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

--- In xpl-dev@y..., "Thomas Poe" <tompoe@p...> wrote:
Hello:  While you guys are at it, I need you to short-circuit the 
present xml dilemma with your xml/xpl approach.

I have a vision of utilizing xml and xsl to house a medical 
terminology project.  The bottleneck lies with XLINK.  You know, 
providing related topic information through one "window" without 
sending the visitor/client off to other web pages.
http://www.worldccr.org/xmloriginal.htm and run your cursor over the 
globe image in the "i-frame".

It seems like a little xpl magic processing, or scripting if-you-
will, makes XLINK viable and independent of the browser.  Marvelous!  
Implement XLINK on the client side, and your paradigm[s] come to 
life, right now, right?  Thanks, Tom
  ----- Original Message ----- 
  From: cagle@o... 
  To: xpl@e... 
  Sent: Thursday, June 15, 2000 9:11 PM
  Subject: Re: [XPL] - WorldOS - framework for distributed computing


  Jonathan,

  I have had many of the same concerns that you share here concerning 
the fact that we are building a very potent, open data environment in 
which a significant amount of the processing takes place with code 
that was never directly written by human hands. When you get right 
down to it, XML has some extremely scary and worrisome implications 
in a number of different areas, because what we're doing is system 
level programming on a global scale. The B2B interactions make up a 
fairly small (and largely unintelligent) part of the whole -- they 
are in many ways least likely to see the neural implications of what 
we're designing.  I see XML as laying waste to vast sectors of our 
existing society without much to replace it -- accounting, 
management, government, manufacturing, programming (most programming 
is not in the gee whiz sector, though it seems that way -- it's in 
the aforementioned fields). I see an increasing number of inventions 
and discoveries coming from human/machine interaction -- by making 
everything open data the mechanisms for performing contextual 
analysis on the space improve immensely -- but this comes at a time 
when we are beginning to question the advancement of knowledge solely 
for the sake of knowledge (cf., Bill Joy).

  The one thing that bothers me so much about XML and its impact on 
the web is that we are reaching a point where the ethical dimensions 
of what we are doing are beginning to become manifest. Privacy is 
already a casualty, cultural cohesiveness is moving in that 
direction. Perhaps we are indeed in the process of waking up Gaea, 
but is a meta-intelligence necessarily a good thing? Even on a less 
metaphysical layer, have we made the changes in our own society to 
accomodate this thing we are unleashing.  My seven year old daughter 
already knows how to type, read at a sixth grade level, do basic 
algebra and surf the net like a pro. Yet I don't think that our 
educational system taught her this; these were emergent behaviors as 
those synapses adopted to the environment around her. What will 
happen with all of these children who are not really being prepared 
for a world that is radically different from anything that you and I 
knew from our days as children?

  Finally, consider that the combination of thousands of computers 
working with common data are more than equivalent to one massively 
parallel system, then think about the fact that an XML vocabulary 
already exists for describing the human genome. I'll leave you to 
draw your own conclusions about that disturbing confluence.

  Okay, so enough with the doom and gloom. The question is how to 
make it happen (I've always wanted to bring about the end of the 
world, looks like I'll finally get my chance !<grin/>

  WorldOS looks intriguing, though I'm beginning to detect a trend 
here that may be worth exploring.  Just as XML is beginning to 
encompass a fairly broad number of different technologies, I think it 
is a reasonable assessment to make that no XML programming language 
can in and of itself hope to be complete. Some work better as 
functional languages within a declarative paradigm within server 
instances, others are basically descriptions of object oriented 
structures within procedural paradigms that are mapped into XML. 
Rather than going around in circles trying to decide which approach 
should or should not be adopted, why not go the inclusive route -- 
set up the XPL site as a site for XML Programming Languages. This 
will give people a chance to look at different routes to solving 
similar problems; I suspect that initially there will be a smattering 
of recommendations that turn into a number of different proto-
languages, which could then in turn be consolidated into best fit 
solutions.  

  Comments?

  -- Kurt Cagle
    ----- Original Message ----- 
    From: Jonathan Burns 
    To: xpl@e... 
    Sent: Friday, June 16, 2000 5:07 AM
    Subject: Re: [XPL] - WorldOS - framework for distributed computing


    Richard Anthony Hein wrote: 
        
        Everyone,There is something called WorldOS that is a 
framework for distributed computing that could be useful to XPL.  If 
you read some of my other posts you will know why I like the idea of 
using such a framework. It includes "a simple TCP server, an XML 
oriented application server, and tools for peer routing similar to 
Freenet or Gnutella.  The application server uses a new protocol 
distinguished by pluggable transports, XML message content, and 
asynchronous messaging."It's opensource, so that's good, and it's in 
the early stages of development, but does function.  So we could get 
our input in there once we have an architecture for XPL, that would 
make WorldOS even better for our purposes.  Anyways, take a look at 
http://www.worldos.org/worldos/index.php3 to get the details.Richard 
A. Hein
      
    So happens, I've just stumbled onto WorldOS myself. 
    This was just after I'd gained a clue what Gnutella is. 

    (Gnutella is a search engine for files. Load a query for some 
file 
    by name. The query fans out among all the Gnutella users your 
system 
    can find, and all that THEY can find, recursively. With luck, 
download 
    access to the file(s) you're after will eventually be passed back 
to you, 
    and show up in a window. Meanwhile, your system is picking up its 
end 
    of other users' searches.) 

    And Napster, which does the same kind of thing for MP3s music 
files. 

    And FreeNet, which gets you onto a web of, shall we say process 
or user 
    identities, allowing exchange of data on an IP-independent basis, 
more 
    or less untraceable by the usual TCP/IP methods. 

    Furthermore, this is after I have been reading and hearing for 
some time 
    about: 

    PunkNet, an architecture like FreeNet. 

    Linda, a network OS and language in which "tuples" circulate 
through 
    data stores on widely distributed machines, being gathered and 
processed 
    by some kind of content search. 

    Seti@Home. 

    The Morris Internet Worm, and others of its kind. 

    To cap it off... 

    Check out Kurt Cagle's  slideshow  on VBXML. It's couched in 
general principles, 
    but if I have it right, Kurt's vision is of free-floating, call-
'em-by-name 
    XML documents, which encapsulate LOCATION and PROTOCOL, so as to 
present the 
    casual user with a web of data bound to data, leading wherever 
you want to go 
    via search-engine interfacing. No more searching for a site, 
going there, 
    accessing the FTP or whatever, and finally accessing the data you 
want by name. 
      

    This is looking like a paradigm. 
      

    Now I completely agree, Richard, that we should investigate 
WorldOS - and maybe 
    make common cause with it. See, WorldOS will evidently conduct 
any XML documents. 
    So if we maintain a layer within XPL development which is Pure 
XML - no processing 
    primitives, no COM hooks, no binding to external mechanisms - 
then WorldOS will 
    function as a transparent distributed mechanism for that layer. 
Technically, it's 
    a potent tool for us. 

    But sheesh. 

    Is anybody as unnerved as I am, about the implications of "data 
gas" webs like this, 
    especially when people like us are going round, endowing them 
with full processing 
    capability? 

    Call me conservative. I spend a lot of time fuming about how free 
markets have 
    diffused the consequences of actions beyond the point where 
anyone can be imputed 
    responsibility for them. Collectively, we've committed ourselves 
to a world society, 
    while disabling the corrective checks and balances that a society 
needs, against 
    the concentration of power. 

    The Web is the same, in fast-forward. It's this fast, not because 
of communication 
    speed, but because there's so little power involved in publishing 
and scanning 
    information, that it's relatively harmless. But already, the Web 
is facing a massive 
    contradiction: intellectual propery funds it, but its consequence 
is the devaluation 
    of intellectual property. 

    What happens when information is completely dissociated from 
authorship? 

    When programs are completely dissociated from authorship? 

    When worms can be released in perfect anonymity? 

    When you can't tell the good worms, like Seti@Home, from the bad 
worms, or from 
    worms like Napster which sidestep around intellectual propery? 

    When there is no such thing as a trusted source? 
      

    Well, that's the New Economy Political Agenda, anyway. 

    On a more technical plane, what bemuses me is, how do we find 
things in a data gas? 

    Answer: We refer to them by content rather than location - and we 
use personal 
    or site caches to nail down copies or shortcut addresses. At a 
guess, if or when 
    we go and implement an XPL data gas, we will be using XML tech to 
implement 
    the Universal Resource Access mechanism we need. XPath on 
steroids, man. 

    <spooky> 

    I've got this vision, of an ocean of little XML thingies - parse 
trees on the loose. 
    They leaf out in typed nodes. Spotlights sweep across the ocean - 
people and their 
    sundry bots, paying attention, and thereby supplying CPU power to 
the thingies. 

    Thingy awakens. It finds a phone. Good morning switchboard, I'm 
looking for stuff 
    with these types and content and timestamp and authentication 
(that's my leaves). 
    Oh, you got some - good. 

    Instantly, thingy is linked up with others of its kind, making a 
temporary Big Thingy. 
    And so on recursively. At some point, all the leaves are filled 
in, down to primitive 
    elements, and there's some XPL present, which activates its 
XSLTs, and the whole Big 
    Thingy goes to work - on borrowed CPU power, from a multitude of 
sources. 

    Presently, Big Thingy has bred a bunch of children, and put them 
on the phone to 
    the people and bots who originally requested whatever services. 
They get linked 
    up with GUI thingies, which deliver the service to the end user. 
End user satisfied, 
    spotlights blink off, thingies go back to sleep. But some 
middlesize thingies are 
    bigger now, or more current. They contain a little bit of 
information on the 
    late transaction, cached away, ready for the next time. 
      

    The whole thing has more than a passing resemblance to brain 
function. 

    Furthermore, it has a close structural resemblance to John Koza's 
Genetic Programming 
    paradigm. 

    Here again we have parse trees on the loose - Lisp expressions. 
Here again we 
    have the free-floating population. From the population, a 
quantity of elements 
    are selected, and activated. They are programs - feed them to a 
Lisp interpreter 
    (spotlight) and they run. This can be done in parallel. It can be 
done like Seti@Home. 
    It's a data gas. 

    The outputs of the programs are collected, and scored. Depending 
on its score, each 
    activated element is given breeding instructions - drop out, or 
replicate yourself, 
    or split apart, or split and recombine with some other element, 
on a type-compatible 
    basis. 

    A new spotlight comes on. In its warm glow, the elements follow 
their instructions. 
    The population is modified. Collectively, it now contains more 
elements which are 
    fitter, more likely to score high. And it contains many elements 
which were parts 
    of fit individuals, and statistically likely to have contributed 
to their success. 

    It's an evolving data gas. 

    </spooky> 
      

    Kltpzyxm! 
    Jonathan 

    His wit never failed him, and he laughed himself to death 
    over a book of the dying words of famous men. 

    - Thomas M. Disch, Camp Concentration. 
      
      
      
      
      


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

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




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



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

[exprla-devel] Re: [XPL] - WorldOS - framework for distributed computing

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

--- In xpl-dev@y..., cagle@o... wrote:
Jonathan,

I have had many of the same concerns that you share here concerning 
the fact that we are building a very potent, open data environment in 
which a significant amount of the processing takes place with code 
that was never directly written by human hands. When you get right 
down to it, XML has some extremely scary and worrisome implications 
in a number of different areas, because what we're doing is system 
level programming on a global scale. The B2B interactions make up a 
fairly small (and largely unintelligent) part of the whole -- they 
are in many ways least likely to see the neural implications of what 
we're designing.  I see XML as laying waste to vast sectors of our 
existing society without much to replace it -- accounting, 
management, government, manufacturing, programming (most programming 
is not in the gee whiz sector, though it seems that way -- it's in 
the aforementioned fields). I see an increasing number of inventions 
and discoveries coming from human/machine interaction -- by making 
everything open data the mechanisms for performing contextual 
analysis on the space improve immensely -- but this comes at a time 
when we are beginning to question the advancement of knowledge solely 
for the sake of knowledge (cf., Bill Joy).

The one thing that bothers me so much about XML and its impact on the 
web is that we are reaching a point where the ethical dimensions of 
what we are doing are beginning to become manifest. Privacy is 
already a casualty, cultural cohesiveness is moving in that 
direction. Perhaps we are indeed in the process of waking up Gaea, 
but is a meta-intelligence necessarily a good thing? Even on a less 
metaphysical layer, have we made the changes in our own society to 
accomodate this thing we are unleashing.  My seven year old daughter 
already knows how to type, read at a sixth grade level, do basic 
algebra and surf the net like a pro. Yet I don't think that our 
educational system taught her this; these were emergent behaviors as 
those synapses adopted to the environment around her. What will 
happen with all of these children who are not really being prepared 
for a world that is radically different from anything that you and I 
knew from our days as children?

Finally, consider that the combination of thousands of computers 
working with common data are more than equivalent to one massively 
parallel system, then think about the fact that an XML vocabulary 
already exists for describing the human genome. I'll leave you to 
draw your own conclusions about that disturbing confluence.

Okay, so enough with the doom and gloom. The question is how to make 
it happen (I've always wanted to bring about the end of the world, 
looks like I'll finally get my chance !<grin/>

WorldOS looks intriguing, though I'm beginning to detect a trend here 
that may be worth exploring.  Just as XML is beginning to encompass a 
fairly broad number of different technologies, I think it is a 
reasonable assessment to make that no XML programming language can in 
and of itself hope to be complete. Some work better as functional 
languages within a declarative paradigm within server instances, 
others are basically descriptions of object oriented structures 
within procedural paradigms that are mapped into XML. Rather than 
going around in circles trying to decide which approach should or 
should not be adopted, why not go the inclusive route -- set up the 
XPL site as a site for XML Programming Languages. This will give 
people a chance to look at different routes to solving similar 
problems; I suspect that initially there will be a smattering of 
recommendations that turn into a number of different proto-languages, 
which could then in turn be consolidated into best fit solutions.  

Comments?

-- Kurt Cagle
  ----- Original Message ----- 
  From: Jonathan Burns 
  To: xpl@e... 
  Sent: Friday, June 16, 2000 5:07 AM
  Subject: Re: [XPL] - WorldOS - framework for distributed computing


  Richard Anthony Hein wrote: 
      
      Everyone,There is something called WorldOS that is a framework 
for distributed computing that could be useful to XPL.  If you read 
some of my other posts you will know why I like the idea of using 
such a framework. It includes "a simple TCP server, an XML oriented 
application server, and tools for peer routing similar to Freenet or 
Gnutella.  The application server uses a new protocol distinguished 
by pluggable transports, XML message content, and asynchronous 
messaging."It's opensource, so that's good, and it's in the early 
stages of development, but does function.  So we could get our input 
in there once we have an architecture for XPL, that would make 
WorldOS even better for our purposes.  Anyways, take a look at 
http://www.worldos.org/worldos/index.php3 to get the details.Richard 
A. Hein
    
  So happens, I've just stumbled onto WorldOS myself. 
  This was just after I'd gained a clue what Gnutella is. 

  (Gnutella is a search engine for files. Load a query for some file 
  by name. The query fans out among all the Gnutella users your 
system 
  can find, and all that THEY can find, recursively. With luck, 
download 
  access to the file(s) you're after will eventually be passed back 
to you, 
  and show up in a window. Meanwhile, your system is picking up its 
end 
  of other users' searches.) 

  And Napster, which does the same kind of thing for MP3s music 
files. 

  And FreeNet, which gets you onto a web of, shall we say process or 
user 
  identities, allowing exchange of data on an IP-independent basis, 
more 
  or less untraceable by the usual TCP/IP methods. 

  Furthermore, this is after I have been reading and hearing for some 
time 
  about: 

  PunkNet, an architecture like FreeNet. 

  Linda, a network OS and language in which "tuples" circulate 
through 
  data stores on widely distributed machines, being gathered and 
processed 
  by some kind of content search. 

  Seti@Home. 

  The Morris Internet Worm, and others of its kind. 

  To cap it off... 

  Check out Kurt Cagle's  slideshow  on VBXML. It's couched in 
general principles, 
  but if I have it right, Kurt's vision is of free-floating, call-'em-
by-name 
  XML documents, which encapsulate LOCATION and PROTOCOL, so as to 
present the 
  casual user with a web of data bound to data, leading wherever you 
want to go 
  via search-engine interfacing. No more searching for a site, going 
there, 
  accessing the FTP or whatever, and finally accessing the data you 
want by name. 
    

  This is looking like a paradigm. 
    

  Now I completely agree, Richard, that we should investigate 
WorldOS - and maybe 
  make common cause with it. See, WorldOS will evidently conduct any 
XML documents. 
  So if we maintain a layer within XPL development which is Pure XML -
 no processing 
  primitives, no COM hooks, no binding to external mechanisms - then 
WorldOS will 
  function as a transparent distributed mechanism for that layer. 
Technically, it's 
  a potent tool for us. 

  But sheesh. 

  Is anybody as unnerved as I am, about the implications of "data 
gas" webs like this, 
  especially when people like us are going round, endowing them with 
full processing 
  capability? 

  Call me conservative. I spend a lot of time fuming about how free 
markets have 
  diffused the consequences of actions beyond the point where anyone 
can be imputed 
  responsibility for them. Collectively, we've committed ourselves to 
a world society, 
  while disabling the corrective checks and balances that a society 
needs, against 
  the concentration of power. 

  The Web is the same, in fast-forward. It's this fast, not because 
of communication 
  speed, but because there's so little power involved in publishing 
and scanning 
  information, that it's relatively harmless. But already, the Web is 
facing a massive 
  contradiction: intellectual propery funds it, but its consequence 
is the devaluation 
  of intellectual property. 

  What happens when information is completely dissociated from 
authorship? 

  When programs are completely dissociated from authorship? 

  When worms can be released in perfect anonymity? 

  When you can't tell the good worms, like Seti@Home, from the bad 
worms, or from 
  worms like Napster which sidestep around intellectual propery? 

  When there is no such thing as a trusted source? 
    

  Well, that's the New Economy Political Agenda, anyway. 

  On a more technical plane, what bemuses me is, how do we find 
things in a data gas? 

  Answer: We refer to them by content rather than location - and we 
use personal 
  or site caches to nail down copies or shortcut addresses. At a 
guess, if or when 
  we go and implement an XPL data gas, we will be using XML tech to 
implement 
  the Universal Resource Access mechanism we need. XPath on steroids, 
man. 

  <spooky> 

  I've got this vision, of an ocean of little XML thingies - parse 
trees on the loose. 
  They leaf out in typed nodes. Spotlights sweep across the ocean - 
people and their 
  sundry bots, paying attention, and thereby supplying CPU power to 
the thingies. 

  Thingy awakens. It finds a phone. Good morning switchboard, I'm 
looking for stuff 
  with these types and content and timestamp and authentication 
(that's my leaves). 
  Oh, you got some - good. 

  Instantly, thingy is linked up with others of its kind, making a 
temporary Big Thingy. 
  And so on recursively. At some point, all the leaves are filled in, 
down to primitive 
  elements, and there's some XPL present, which activates its XSLTs, 
and the whole Big 
  Thingy goes to work - on borrowed CPU power, from a multitude of 
sources. 

  Presently, Big Thingy has bred a bunch of children, and put them on 
the phone to 
  the people and bots who originally requested whatever services. 
They get linked 
  up with GUI thingies, which deliver the service to the end user. 
End user satisfied, 
  spotlights blink off, thingies go back to sleep. But some 
middlesize thingies are 
  bigger now, or more current. They contain a little bit of 
information on the 
  late transaction, cached away, ready for the next time. 
    

  The whole thing has more than a passing resemblance to brain 
function. 

  Furthermore, it has a close structural resemblance to John Koza's 
Genetic Programming 
  paradigm. 

  Here again we have parse trees on the loose - Lisp expressions. 
Here again we 
  have the free-floating population. From the population, a quantity 
of elements 
  are selected, and activated. They are programs - feed them to a 
Lisp interpreter 
  (spotlight) and they run. This can be done in parallel. It can be 
done like Seti@Home. 
  It's a data gas. 

  The outputs of the programs are collected, and scored. Depending on 
its score, each 
  activated element is given breeding instructions - drop out, or 
replicate yourself, 
  or split apart, or split and recombine with some other element, on 
a type-compatible 
  basis. 

  A new spotlight comes on. In its warm glow, the elements follow 
their instructions. 
  The population is modified. Collectively, it now contains more 
elements which are 
  fitter, more likely to score high. And it contains many elements 
which were parts 
  of fit individuals, and statistically likely to have contributed to 
their success. 

  It's an evolving data gas. 

  </spooky> 
    

  Kltpzyxm! 
  Jonathan 

  His wit never failed him, and he laughed himself to death 
  over a book of the dying words of famous men. 

  - Thomas M. Disch, Camp Concentration. 
    
    
    
    
    


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



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

[exprla-devel] Re: [XPL] - WorldOS - framework for distributed computing

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

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

>
>
>      Everyone,There is something called WorldOS that is a
>      framework for distributed computing that could be useful to
>      XPL.  If you read some of my other posts you will know why I
>      like the idea of using such a framework. It includes "a
>      simple TCP server, an XML oriented application server, and
>      tools for peer routing similar to Freenet or Gnutella.  The
>      application server uses a new protocol distinguished by
>      pluggable transports, XML message content, and asynchronous
>      messaging."It's opensource, so that's good, and it's in the
>      early stages of development, but does function.  So we could
>      get our input in there once we have an architecture for XPL,
>      that would make WorldOS even better for our purposes.
>      Anyways, take a look at
>      http://www.worldos.org/worldos/index.php3 to get the
>      details.Richard A. Hein
>

So happens, I've just stumbled onto WorldOS myself.

This was just after I'd gained a clue what Gnutella is.

(Gnutella is a search engine for files. Load a query for some file
by name. The query fans out among all the Gnutella users your system
can find, and all that THEY can find, recursively. With luck, download
access to the file(s) you're after will eventually be passed back to
you,
and show up in a window. Meanwhile, your system is picking up its end
of other users' searches.)

And Napster, which does the same kind of thing for MP3s music files.

And FreeNet, which gets you onto a web of, shall we say process or 
user
identities, allowing exchange of data on an IP-independent basis, more
or less untraceable by the usual TCP/IP methods.

Furthermore, this is after I have been reading and hearing for some 
time

about:

PunkNet, an architecture like FreeNet.

Linda, a network OS and language in which "tuples" circulate through
data stores on widely distributed machines, being gathered and 
processed

by some kind of content search.

Seti@Home.

The Morris Internet Worm, and others of its kind.

To cap it off...

Check out Kurt Cagle's  slideshow  on VBXML. It's couched in general
principles,
but if I have it right, Kurt's vision is of free-floating,
call-'em-by-name
XML documents, which encapsulate LOCATION and PROTOCOL, so as to 
present
the
casual user with a web of data bound to data, leading wherever you 
want
to go
via search-engine interfacing. No more searching for a site, going
there,
accessing the FTP or whatever, and finally accessing the data you want
by name.


This is looking like a paradigm.


Now I completely agree, Richard, that we should investigate WorldOS -
and maybe
make common cause with it. See, WorldOS will evidently conduct any XML
documents.
So if we maintain a layer within XPL development which is Pure XML - 
no
processing
primitives, no COM hooks, no binding to external mechanisms - then
WorldOS will
function as a transparent distributed mechanism for that layer.
Technically, it's
a potent tool for us.

But sheesh.

Is anybody as unnerved as I am, about the implications of "data gas"
webs like this,
especially when people like us are going round, endowing them with 
full
processing
capability?

Call me conservative. I spend a lot of time fuming about how free
markets have
diffused the consequences of actions beyond the point where anyone can
be imputed
responsibility for them. Collectively, we've committed ourselves to a
world society,
while disabling the corrective checks and balances that a society 
needs,
against
the concentration of power.

The Web is the same, in fast-forward. It's this fast, not because of
communication
speed, but because there's so little power involved in publishing and
scanning
information, that it's relatively harmless. But already, the Web is
facing a massive
contradiction: intellectual propery funds it, but its consequence is 
the
devaluation
of intellectual property.

What happens when information is completely dissociated from 
authorship?

When programs are completely dissociated from authorship?

When worms can be released in perfect anonymity?

When you can't tell the good worms, like Seti@Home, from the bad 
worms,
or from
worms like Napster which sidestep around intellectual propery?

When there is no such thing as a trusted source?


Well, that's the New Economy Political Agenda, anyway.

On a more technical plane, what bemuses me is, how do we find things 
in
a data gas?

Answer: We refer to them by content rather than location - and we use
personal
or site caches to nail down copies or shortcut addresses. At a guess, 
if
or when
we go and implement an XPL data gas, we will be using XML tech to
implement
the Universal Resource Access mechanism we need. XPath on steroids, 
man.

<spooky>

I've got this vision, of an ocean of little XML thingies - parse trees
on the loose.
They leaf out in typed nodes. Spotlights sweep across the ocean - 
people
and their
sundry bots, paying attention, and thereby supplying CPU power to the
thingies.

Thingy awakens. It finds a phone. Good morning switchboard, I'm 
looking
for stuff
with these types and content and timestamp and authentication (that's 
my
leaves).
Oh, you got some - good.

Instantly, thingy is linked up with others of its kind, making a
temporary Big Thingy.
And so on recursively. At some point, all the leaves are filled in, 
down
to primitive
elements, and there's some XPL present, which activates its XSLTs, and
the whole Big
Thingy goes to work - on borrowed CPU power, from a multitude of
sources.

Presently, Big Thingy has bred a bunch of children, and put them on 
the
phone to
the people and bots who originally requested whatever services. They 
get
linked
up with GUI thingies, which deliver the service to the end user. End
user satisfied,
spotlights blink off, thingies go back to sleep. But some middlesize
thingies are
bigger now, or more current. They contain a little bit of information 
on
the
late transaction, cached away, ready for the next time.


The whole thing has more than a passing resemblance to brain function.

Furthermore, it has a close structural resemblance to John Koza's
Genetic Programming
paradigm.

Here again we have parse trees on the loose - Lisp expressions. Here
again we
have the free-floating population. From the population, a quantity of
elements
are selected, and activated. They are programs - feed them to a Lisp
interpreter
(spotlight) and they run. This can be done in parallel. It can be done
like Seti@Home.
It's a data gas.

The outputs of the programs are collected, and scored. Depending on 
its
score, each
activated element is given breeding instructions - drop out, or
replicate yourself,
or split apart, or split and recombine with some other element, on a
type-compatible
basis.

A new spotlight comes on. In its warm glow, the elements follow their
instructions.
The population is modified. Collectively, it now contains more 
elements
which are
fitter, more likely to score high. And it contains many elements which
were parts
of fit individuals, and statistically likely to have contributed to
their success.

It's an evolving data gas.

</spooky>


Kltpzyxm!
Jonathan

His wit never failed him, and he laughed himself to death
over a book of the dying words of famous men.

- Thomas M. Disch, Camp Concentration.
--- End forwarded message ---

[exprla-devel] [XPL] - WorldOS - framework for distributed computing

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
  Everyone,
  There is something called WorldOS that is a framework for 
distributed
computing that could be useful to XPL.  If you read some of my other 
posts
you will know why I like the idea of using such a framework.

  It includes "a simple TCP server, an XML oriented application 
server, and
tools for peer routing similar to Freenet or Gnutella.  The 
application
server uses a new protocol distinguished by pluggable transports, XML
message content, and asynchronous messaging."

  It's opensource, so that's good, and it's in the early stages of
development, but does function.  So we could get our input in there 
once we
have an architecture for XPL, that would make WorldOS even better for 
our
purposes.  Anyways, take a look at 
http://www.worldos.org/worldos/index.php3
to get the details.


  Richard A. Hein
--- End forwarded message ---

[exprla-devel] Re: Requirements for Discussion

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

--- In xpl-dev@y..., "Richard Hein" <935551@i...> wrote:
Jonathan,

For what it's worth, your list looks really good and covers a lot of 
what I think XPL should require as well.  Comments are included below.

--- In xpl@e..., Jonathan Burns <saski@w...> wrote:
> It's late at night, and I realize that the following needs serious
> editing. Nonetheless, the intent should mostly be clear...
> 
> Requirements:
> 
> 
> 1. XPL will be a set of conventions for representing algorithms
>   as XML documents.

This is good, but maybe we should say it's a language for 
representing algorithms as XML documents, as opposed to being a set 
of conventions.  This may be picky, but the requirements should be 
clear.

> 
>   It will include conventions for representing algorithms of
>   at least the following kinds:
> 
>   1.1  Tree-structured expressions, combining typed operands
>        and operators.
> 
>   1.2  Procedural control-flow, including the standard loop
>        and conditional constructions.
> 
>   1.3  Typed function calls, comprising "protocols" (OOP),
>        i.e. "signatures" (abstract data types).
> 
>   1.4  Rule-based transformations of tree-structured expressions.
> 
>   1.5  Aggregation of function protocols into class interfaces.

This is a requirement that needs discussion, as we are not clear on 
how to handle classes, if we are going to at all (within the XPL 
language itself I mean).  However, the requirement itself is probably 
fine, as we do need to provide a way to access classes in external 
sources, like C++ and so on.  If in the end, we don't use classes in 
XPL however, this requirement may have to be changed to make it clear 
that the class interfaces are for classes outside of XPL itself.  
Otherwise people who read this will automatically assume that XPL 
uses classes as part of it's architecture.

> 
>   1.6  Aggregation of interfaces, to allow interface inheritance.

I have no problem with this; it would be a great thing to have!

> 
>   1.7  Binding of external operations to formal XPL operations;
>        e.g. callback functions activated from parsing.
> 
>   1.8  Regular expressions and EBNF grammars.
> 
>   1.9  Parsers implementing the recognition of regular expressions
>        and grammars.
> 
>   1.10 Declaration of storage locations, with scope and lifetime
>        determined by the decaring XPL program.
> 
>   1.11 Reference to storage locations by URLs or URIs.

It's possible that we may be able to use OID's as decribed in 
www.xmlhack.com/read.php?item=577.  However, we would have to change 
it to make it resolvable.  If anyone with a good knowledge of URIs 
and namespaces could check it out and comment, it would be helpful - 
I could be totally off base here.

> 
>   1.12 Generation of XPL elements by external events.

Could you give me an example Jonathan?  Do you just mean calls to XPL 
that instantiate an object, or calls to methods that generate XPL?  
Sorry, I'm not sure what you are referring to.

> 
> 2. XPL will include a standard architecture for XPL parsers,
>    and for XPL operations, which may be ported to any reasonable
>    processing system.

Definetely.

> 
> 3. XPL will be reflexive, i.e. self-descriptive

A+

> 
> 4. XPL will be developed in the context of, and following the
>    example of, open standards for XML document handling, as
>    documented in W3C/XML standards literature. Whenever a
>    requirement can be completely met by the use of documented
>    W3C/XML mechanisms, that use will be preferred to any other
>    which entails mechanisms external to W3C/XML.

For sure.  We should really be able to take all the valuable work, 
like XSLT and XPath and use it in XPL as if it were native to XPL.  I 
kind of picture XPL as being a place where all the W3C specs come 
together under one language architecture, and where the current specs 
fall short, we extend using XPL specific language.  There is so many 
new specs being developed and it looks like XML is going to suffer 
the Babel effect ...  XML, XSL, XSLT, XPath, XPointer, XLink, X(fill 
in the blank), that it's just plain nutty.  If we can consolidate it 
into XPL ... well, you can all see the benefits of that.

> 
> 5. XPL will be developed under a recognized open-source charter,
>    permitting access of official XPL sources to any party.
>    Confidential sources will not be recognized as part of XPL.

Absolutely!

> 
> 6. The XPL architecture (yet to be defined) will include both
>    interface definitions and their implementations. It will
>    require that interfaces and implementation be defined in
>    distinct documents, such that interfaces may be published
>    independently of any implementation.

Good.

> 
> 7. The XPL architecture will include both formal distributed
>    processes, and processors on which they are to execute.
>    It will require that formal and actual processors be defined
>    in distinct documents, such that formal distributed processes
>    may be published independently of how they will be mapped
>    onto networks.
> 
> 8. XPL will include XML documents which subsume existing interface
>    definition schemes (such as COM, CORBA).
> 
> 9. XPL will be developed subject to the goal of providing a means
>    of programming for Web content, which is as simple and
>    accessible as possble.
 
I like this better:  

XPL will be developed subject to the goal of providing a means of 
programming for bi-directional Web applications, services, components 
and content, which is as simple and accessible as possible.

> 10. XPL documentation and tutorial materials will take special
>     consideration of the requirements of the handicapped, the
>     young, and non-English speakers.
> 

Excellent stuff Jonathan, I agree with your requirements, and look 
forward to futher review!


Richard A. Hein
--- End forwarded message ---

[exprla-devel] Re: [XPL] Little Languages in XML

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

--- In xpl-dev@y..., Rod Moten <rod@c...> wrote:
At 10:11 AM 6/15/00 -0000, you wrote:
>URL: www.xmldevcon2000.com/sessions/session.cfm?page=n1
>
>> Little Languages in XML
>>
>> A "little language" is a computer language that implements some 
sort
>> of non-general functionality. This session will explain the design
>> and implementation of domain specific little languages in XML.
>> We'll discuss one specific little language - a tool for extracting
>> data from a database and displaying it in a HTML table.
>>
>> Matt Sergeant has worked exclusively with Perl for 3 years
>> and is co-authoring a book called XML Applications with Perl.
>
>Does this relate to XPL in any way?

If understand the manifesto of XPL correctly, I believe with XPL you 
will
create little languages or more concretely domain specific languages. 

Rod
--- End forwarded message ---

[exprla-devel] Little Languages in XML

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

--- In xpl-dev@y..., "Alexander Gutman" <gutman@m...> wrote:
URL: www.xmldevcon2000.com/sessions/session.cfm?page=n1

> Little Languages in XML
>
> A "little language" is a computer language that implements some sort
> of non-general functionality. This session will explain the design
> and implementation of domain specific little languages in XML.
> We'll discuss one specific little language - a tool for extracting
> data from a database and displaying it in a HTML table.
>
> Matt Sergeant has worked exclusively with Perl for 3 years
> and is co-authoring a book called XML Applications with Perl.

Does this relate to XPL in any way?

--
Alexander E. Gutman
--- End forwarded message ---

[exprla-devel] [XPL] requirements

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Here is my list of XPL requirements I have come up with so far.  Feel 
free
to tear them up and spit them out if you disagree, or to support them 
if you
agree.  I have put the requirement in, with an explanation of why, as 
well
as source information to help people find out more about what I am 
saying,
below the requirement.

1.  XPL must not depend on the Document Object Model.

This is because DOM cannot be a universal API for XML - and it is not 
really
an object model at all; it's a collection of IDL interfaces:  see
http://www.prescod.net/groves/shorttut/ section 2.2 for information 
on "Why
not the DOM" for more info. if you are not convinced.

2.  XPL should leverage the ISO standard of Groves (or the grove 
paradigm)
for addressing any media type.

Groves can be used to address any media, such as frames in a mpeg, or
characters in a documents.  If we use Groves to address data, we can 
use XPL
to manipulate it and put it back in the media (if it is not read-
only), or
output to another media type.  Read 
http://www.prescod.net/groves/shorttut/
or http://www.xml.com/pub/2000/04/19/groves/index.html for 
explanations
about Groves.  I just thought of this today, and it may be premature 
to
recommend it as a requirement, so I encourage everyone to check out 
at least
one of the articles.  The second one is short and straight to the 
point.  A
Grove, for those not familiar, is "a meta-'data model' for media
applications" according to the first article's author.

3.  XPL must be human readable.

Just a common requirement for all XML related specifications, although
obvious, should be on the requirements list.

4.  XPL will use XSL and XSLT instructions, which can be 
accessed/embedded
from/in XPL code, for formatting, and transformations.

XPL must have an integrated XSLT processor, because if you write a 
program
that is compiled, you may not want people to format it differently, 
so you
should be able to compile the XSLT along with the rest of the XPL 
code, as a
whole.

5.  XPL will leverage/support SOAP and ebXML to facilitate 
communication and
transport between heterogenous components, and provide a simple means 
to
refer to the source and interfaces to those components as variables.

We have to support both SOAP and ebXML, because we don't know which 
will
become the most widely utilized yet.  However, the language of XPL 
should be
the same when using either one, excepting the instantiation and 
declaration
of the components location and interfaces of course.  So I should be 
able to
switch between SOAP and ebXML that call the same components by simply
changing the transport type declaration.  However, I am not sure I 
fully
understand this yet.

Well, that's it for now.  These may seem general, but I think they 
should
be, to leave room for the architecture.  I want to say, however, that 
all of
these requirements are coming from someone who isn't the best person 
in the
world to make a list of requirements and such.  So take these all 
with a
grain of salt until you give it some thought.  That is, don't assume I
really know what I am talking about ... the more I think about XPL 
(which is
a lot now), the more I realize just how little I know about the way
languages really work.

It's like someone being able to write essays in decent English, 
because they
read a lot, but they don't fully understand the underlying principles 
of
grammer.  They simply have it built in by the time they put pen to 
paper.

This is a difficult admission for me to make, but it's the truth, and 
I
don't want people to depend on my input without making an educated
evaluation of what I am saying.  I'm not even sure if I can be a 
valuable
contributer to this project, due to these facts, but I'm really 
trying, and
will stick with it as long as I can, and learn a lot along the way.  
Up
until now, I have just been developing database applications, and 
taken
language constructs for granted - this is something totally different.


Richard A. Hein
--- End forwarded message ---

[exprla-devel] Hmm, Another Idea....

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

--- In xpl-dev@y..., Michael Lauzon <ce940@f...> wrote:
I think we can do two directions for XPL at once.  I still think we 
should make open source versions of Miva, Cold Fusion & Tango; but 
the 
XPL that will eventually handle that should be called XPLScript 
(XPLS).  
Though they will be based on XPL, what doesn't go to XPL can go to 
XPLScript. 

Michael
http://www.geocities.com/SiliconValley/Way/9180/

'Eat, drink, and be merry, for tomorrow you may work.'
--- End forwarded message ---

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., cagle@o... wrote:
Jonathon,

Not wanting to reiterate your arguments (which are quite nice, by the 
way) I would argue that an XSLT document is not necessarily one 
transformation.  Specifically, if you allow for named templates, then 
the correlation between an XSLT document and a set of class methods 
becomes somewhat stronger, especially if you utilize the <xsl:import> 
command. 

<xsl:stylesheet ...>
    <xsl:import href="subfilters.xsl"/>
    <xsl:param name="method_name"/>
    <xsl:template match="/">
            <xsl:call-template name="{$method_name}">
                    <xsl:with-param name="data" select="."/>
            </xsl:call-template>
    </xsl:template>
</xsl:stylesheet>

In this way, the parameter method_name effectively controls 
which "method" is called. This is effectively your proxy stylesheet.

More tomorrow, when I'm a little more cogent ....
 -- Kurt Cagle
--- End forwarded message ---

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Some commentary on the thread so far:

Alexander Gutman (Sunday 11/06/00) leads off:

At this moment I am thinking about how classes
will be declared in XPL. And I encountered a problem.


AG (if I may) has a <me> element, with <human>,
<mathematician> and <programmer> elements nested within.
And he wants to know how this XPL classic would be
expressed as a class (or strictly, object) in standard
OOP languages.

The obvious way to start off, would be to define a class
for each of the inner elements, and then to define a class
<me>, whose objects contain one instance each of the three,
as private data.

So then the question is, how does he want class <me> to look
from the outside?

Again, the obvious way is to add methods to the <me>
interface: get_human, get_mathematician, get_programmer.
Each of these methods will return a copy of the private
instance of the element. What's nice is that methods
so named can return lists of the desired element; a null
list if the element isn't there in an instance of <me>,
or a list of several, if <me> is a programmer at two
different workplaces.

So it's obviously feasible. As a variation, one can
define class <occupation>, and subclass <mathematician>
and <programmer> from it. Then we could define method:
get_occupation, to return both kinds of element in a
list.


Richard Hein (11/06/00) replies:

So if you use overloading, you call <human>, [etc] as if
they were different functions in the class?

Answer: Yes. But there's no special need for overloading.
If what we want is to provide special interfaces for <me>,
then the interfaces of classes <human>, <mathematician>
etc are just what we want. OOP is working as advertised.

The "different functions" in the class will just be the
different methods, get_human etc, which extract the desired
instances from an instance of <me>.


Then Kurt Cagle comes in with the OTHER side of the question 
(11/06/00):



[...] an XML Schema definition is
more like a VB type statement than a Java class -- the schema defines
the type and positional characteristics of an XML structure, but not 
any

associated methods or events.

However, you could make a superclass
structure that might actually include a schema and an associated
stylesheet with named templates, with templates acting as methods.



The other side of the question is, can we implement some simple
methods using off-the-shelf XML tech?

Answers:

(1) A schema or a DTD for <me> will define the element types
and placement of its private data; e.g. can we have zero or
multiple private instances of <human>? But a schema or a DTD
will not provide us with methods for getting the private
elements out of <me> - or doing anything with them if we could.

(2) XPath will get the inner elements.

child::mathematician()

will do that job directly. And other facilities of XPath will
extract elements of much more complicated documents; and
count and compare and filter them besides. The limitation of
XPath is that all these operations are read-only - they only
ever copy data from a document. There is no provision for
binding additional methods to elements on extraction.

But it is worth noting, that if we are content with public
nested state data in our objects, the get_ methods are
built-in with XPath. To that extent, all XML documents with
some defining schema or DTD are objects already.

(3) XSLT will apply template operations to <me>, acting on
any pattern (i.e. XPath expression) which we provide in
an XSL Transform.

This is the means to provide class <me> with a proper
interface. But, it is not directly adapted to providing
the kind of interface with which we are familiar in OOP.

As far as I can make out, an XSL Transform defines one
method, together with its implementation.

The standard OOP interface consists of many methods,
with or without implementations.

This isn't much of a problem, as far as I can see.
We can certainly have a transform which calls a proxy
template - a stub, which can go on to call the real
method implementation. And we can define an XPL class
interface as a collection of transforms.


Kurt goes on to say:


Keep in mind that the one primary difference between XML and 
procedural
objects is that the XML instance of a schema may not necessarily be
physically connected with the methods that operate on it.

We should thus ask whether XPL works by keeping the XML instance data
of a class as part of the object -- i.e., the XML acts as the local
variables --

 or the XML data arrives as input and is processed in real time 
against
the XPL/XSLT templates (in which case the XPL objects are methods 
only).

The former is a statist approach -- the data needs to be retained
between calls, while the latter is stateless.


Well, I'm not necessarily against statist approaches. The data
has to be stored somewhere, after all - it's just a matter of
how far away we want to push the commitment to stored data.

But we will want to provide an indirection mechanism, where the
data for the pattern to be recognized in a transform is not
present in the object, but is assembled on the fly.

It looks as if such a mechanism has to be built into XPath,
though. For our purpose here, XPath needs to recognize:

        <programmer ref=[URI] >
        </programmer>

or some such.


I will say, that if we develop XPL as statelessly as possible,
we will wind up in the company of the extreme functional languages,
which have to admit constant data eventually; but by that time,
they have pushed it into an obscure corner of the syntax, which
nobody can quite remember. (E.g., you get a major realm tacked on,
of addresses trying to pretend they are get_ functions and
failing.) Such languages do produce some beautiful dataflow
plumbing, however.


Alexander replies  (12/06/00):


Hmm... Could you clarify this idea?

Somewhat clarified, I hope.



As far as I know, the output of a transformation procedure
is always an XML document/object and, furthermore, we cannot
perform any actions during transformation other than those
which reflect the output (probably, the 'eval'; XSL element can
produce some side-effects during transformation, I do not know).


This raises the question, Is XSLT as powerful as we would like?

I'm undecided so far. XSLT provides quite the arsenal of tree-
building operations, and on first glance I can't gauge the
extent of the programming paradigms it supports.

Sometime soon, I'll give you at considerable length the benfits
of my experience with Mathematica, which is based on transformation
rules for tree-structured expressions. It looks very much like
XSLT to me. Mathematica demonstrates that you an do a LOT, just
by munging trees around.

Now my intuition is, when we want to bind "side-effects" to
XSLT, the way to do it is not to embed one dinky external-
language call in every production rule we recognize, but
rather to produce a complete document for whatever we want
an external system to perform. And we pass that document to
a special parser, which has the total API for the external
system bound into it. If we do it that way, then XSLT only
needs to transform trees for us.



So, how can an XSL template act as a method?
It seems that the only thing such a method can do
is returning an XML object. Do you mean that this object
is the body of the method? Or its return value?

The way I've been describing, the XML object is indeed
the return value of the transform, I mean method.


Actually, I thought about methods and discovered another
possibility of associating a method with an element type:
via an attribute whose name is that of the method
and default value the method's body (or its identifier).
However, I am not quite sure that this is a good idea.


We probably wouldn't want to do it with a raw instance
of <me>. In fact I'd argue most  strongly that at a deep
level we want it hardwired in that clients' parsers IGNORE
any references to executable stuff, except under very
specific conditions - e.g. their trusted browser detects
an <xpl:method> tag, and stops to verify that the XPL
document is from a trustworthy source.

However, the place we would actually like to put method
bindings is in XPL-enhanced schemas, which are XML
documents. The way I'm coming to see it, we would like
to provide a schema for each external API we address.


Oh! But didn't I say above that the place for our
methods was XSLT?

Not any more. Let XSLT munge trees.

But look, there's a major redundancy in XML technologies.

Everything which takes XML documents as input, does some
kind of traversal on the tree. Verifying parsers, XPath,
XSLT - they all do it. The fact is, they are all just
different flavours of Parser. They all recognize productions
in XML - that is, elements - as they wander up and down the
tree. They just take different actions at different points.

So there are various places in the XML accessory equipage,
where one might want to tack method hooks on. What we want
to do, is identify the best place to tack them, in order
to provide the standard OOP interface.


(1) Schema or DTD provides a map of the public interface.

(2) XPath, working on the schema, provides a general read-only
navigation interface, with actual get_ methods of many kinds.

(3) XSLT transforms, working on the elements returned by
XPath, provide the set_ methods which rearrange the tree,
and present the results as output.

(4) XSLT transforms also produce output trees (XML documents)
which define actions to be taken by external APIs.

(5) And special external-system parsers take those documents,
and traverse them so as to make the external-system calls
which implement the actions.


And NOW we have separation of interface from implementation.

Well, almost. Above, the schema maps the interface, inasfar
as the interface defines what kinds of elements are present.
It doesn't tell you want non-get_ methods are available.

The XSLTs in (4) and (5) do tell you what those methods are;
in fact so far, we're talking about on transform document
per method. But those transforms are the ones that actually
execute the methods, external side-effects aside.

So we probably do want a method-annotated Schema type for
XPL, which defines the available method interfaces by name
and parameter valence - but leaves the method actions to the
XSLTs.


Alexander has further questions on the OOP issue, but it seems
to me that the picture I'm drawing has a bearing on them all.
What do you think, AG?



Finally (so far), Garreth Galligan (12/06/00) puts the whole
OOP paradigm to the question.

<occupation id="occupation1">
    <title>mathematician</title>
    <workplace>An Institute</workplace>
    <alias>Some Guy</alias>
</occupation>

<occupation id="occupation2">
    <title>programmer</title>
    <workplace>A Company</workplace>
    <alias>Some Guy</alias>
</occupation>


<me>
    <human>
        <name>Alexander Gutman</name>
        <birthdate>1996-07-01</birthdate>
    </human>
    <prototype obj="occupation1">
        <workplace>BlahBlah Institute</workplace>
        <alias>Alex Goodman</alias>
    </prototype>
    <prototype obj="occupation2">
        <alias>Alex Softman</alias>
        <workplace>Foobar Software</workplace>
        <prototype>
            <description>My main job</description>
        </prototype>
    </prototype>
</me>

What we have here is fairly close to the Mathematica style.

Aggregates, let's call them objects, are written out arbitrarily.
By default, they are available as prototypes.

When reused, an object brings in all the data with which it was 
defined.

But any of that data may be overridden. Thus "occupation2" comes with
<title>, <workplace> and <alias> values as originally defined; but
the latter two get new overriding values. The whole <me> object
is available as a new prototype.

It's actually quite elegant - but there are things it can't tell me.
For instance, what if I now want to produce a second <me> instance,
for someone working two shifts as a mathematician. Do the default
rules state that the <programmer> element is copied to the new <me>,
or absent?

This kind of information - elements required, forbidden, unique,
many, etc - is easily included in a schema, once one has gone
to the trouble of building one.

With OOP - classes, schemas, interfaces, whatever - you get
control, for an effort upfront.

How did Mathematica make out, without it?

Not badly, for the most part. What you could do, with a bit of
manual work, was take any hand-made expression and substitute
variable names - named blanks - for chosen elements; the result
was then available as an expression pattern, which would match
the original and anything like it except for the values of
the blanked-out elements. And then, you made the pattern one
side of a rule, which produced a new expression from those
values.

When it came to Real OOP, there was a tendency to tie oneself
in knots. The problem was, if you had a complex structure,
you had to write horrible indexing expressions in quantity, to
abstract out the stuff you wanted to reuse.


I wouldn't rule out this bottom-up prototyping idea. If we can
hand-build this stuff, we can hand-convert it to schema form
with about the same effort.


All the best, cats

Jonathan
--- End forwarded message ---

[exprla-devel] RE: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Ok, I am probably not the best person to try to supply a solution to 
this,
but here's an idea I will throw out.  XPL doesn't need classes, but 
to make
people comfortable we can make them using XPointer.  For example, 
given a
class:

<cycle>
    <wheels/>
     <gears/>
        ...
</cycle>

we could reference this class in a sub-class like so:

<bicycle>
    <xpl:inherits>
       <xpl:inherit <!-- some XPointer reference to superclass
<cycle><wheels/> (I don't know how to do this) -->>
            <!-- add your sub-class stuff here -->
            <wheel>front</wheel> <!-- add children and whatever, even 
point
to other classes -->
       </xpl:inherit>
       </xpl:inherit <!-- XPointer to superclass <cycle><gears> -->
            <gear id="1">
                <ratio>1:1</ratio>
            ...
            </gear>
       </xpl:inherit>
    </xpl:inherits>
</bicycle>

Just a thought.

Richard A. Hein

  -----Original Message-----
  From: cagle@o... [mailto:cagle@o...]
  Sent: June 12, 2000 10:07 PM
  To: xpl@e...
  Subject: Re: [XPL] The structure of classes in XPL


  I'm inclined to agree with you on the class issue. I've worried 
myself
that
  the class paradigm provides a number of limitations to what is 
essentially
a
  classless model. The problems with attempting to use an XML based 
code for
a
  procedural language are unfortunately pretty major, but most boil 
down to
  Occam's razor -- is there any real benefit in coding a procedural 
language
  in XML that can't already be done with DOM? I'd contend that there 
really
  isn't -- most procedural languages work on one piece of  a data 
document
at
  a time, while XSL (as an example) tends to encourage a holistic 
approach
to
  coding: find the relevent patterns in an XML document and apply the
  templates to the data. In this sense, the polymorphism that's done 
takes
  place at the abstract level of designing the XSL templates rather 
than at
  the object level.  I suppose that you could work a registration 
scheme
such
  that when an XML object with a recognized schema "entered the 
gate", so to
  speak, only those XSL filters that recognized the schema would be
considered
  part of its methods, but again I think this falls into the square 
peg,
round
  hole issue.

  I like to think that a better idea might be to associate with a 
document's
  schema a URN that pointed to another XML document that contained the
  interfaces and URLs of XSLT (XPL?) templates that could work on a 
given
  document (or perhaps in turn another pointer document, a la 
Gnutella).
Such
  a registry document might also contain some kind of annotation 
element
akin
  to that found in the XML Schema language, so that an IDE could 
retrieve a
  document, dereference its schema, dereference the templates 
document and
  then display the results as an intellisense like drop-box.

  I think this also opens up the possibility of polymorphism, 
declarative
  style --  there is no reason that two documents with distinct 
schemas
  couldn't reference the same set of templates (if the templates were
general
  enough) nor why you couldn't create a schema that pointed to both a 
base
set
  of templates and an augmented set for providing "subclassing" 
behavior.

  We need to determine whether or not we're writing a procedural or
  declarative language.  I think the idea of writing a general meta-
language
  for programming is ill-advised. Programming languages vary across 
the
board
  from fairly simple scripted languages such as JavaScript to pointer 
driven
  languages such as C++ (I shudder to think of a C++ language 
implementation
  written in XML, to be honest) to text manipulation languages such 
as Perl.
  Moreover, I think that each of these languages does what it does 
quite
well,
  and that it is far more difficult making from one linguistic 
namespace to
  the next. Let's concentrate on extending what already exists, 
making XSLT
  more robust, and developing an IDE that would work for such a 
solution.
  After that we can reprogram the world <grin/>.

  -- Kurt Cagle

  ----- Original Message -----
  From: "Garreth Galligan" <garreth.galligan@o...>
  To: <xpl@e...>
  Sent: Monday, June 12, 2000 8:50 AM
  Subject: Re: [XPL] The structure of classes in XPL


  > When worlds collide, data architecture meets class architecture :)
  > What's good for data: highly ridged, hierarchical and dependent
structures
  > is not necessarily good for a program.
  >
  > We are certainly staring right into the face of some very big and
  > interesting contradictions:
  >
  >
  > Alexander E. Gutman  wrote:
  >
  > >  As soon as XPL is closely related to XML, the structure
  > >  of its classes should be as flexible as XML structures.
  > >  Should we regard classes as XML element types
  > >  (and, probably, declare them via schema element type 
definitions)
  > >  or should we employ a standard approach of some kind?
  >
  > Just to muddy the waters further - Why Classes at all?
  > Do Classes truly have any relevance to XML?
  > Is XML and Classes a square peg in a round hole?
  > Are we forcing OO paradigms on XML for paradigms' sake?
  > I don't have the answers, just a lot of questions :)
  >
  > >  but I wonder if there is a solution close (in flexibility) to 
that of
  XML
  >
  > I risk my neck and offer classless (no pun intended) object-based
  languages
  > (e.g. Self, JavaScript) as an alternative model which perhaps more
closely
  > mirror the flexibility and *simplicity* of XML. XML already 
offers many
of
  > the advantages of a class based system, e.g. encapsulation via
namespaces.
  >
  > This is probably not the best example in the world to display
prototyping,
  > but:
  >
  > <occupation id="occupation1">
  >     <title>mathematician</title>
  >     <workplace>An Institute</workplace>
  >     <alias>Some Guy</alias>
  > </occupation>
  >
  > <occupation id="occupation2">
  >     <title>programmer</title>
  >     <workplace>A Company</workplace>
  >     <alias>Some Guy</alias>
  > </occupation>
  >
  >
  > <me>
  >     <human>
  >         <name>Alexander Gutman</name>
  >         <birthdate>1996-07-01</birthdate>
  >     </human>
  >     <prototype obj="occupation1">
  >         <workplace>BlahBlah Institute</workplace>
  >         <alias>Alex Goodman</alias>
  >     </prototype>
  >     <prototype obj="occupation2">
  >         <alias>Alex Softman</alias>
  >         <workplace>Foobar Software</workplace>
  >         <prototype>
  >             <description>My main job</description>
  >         </prototype>
  >     </prototype>
  > </me>
  >
  > As you can see with the above we are looking at a much simpler 
DTD in
  terms
  > of structural relationships. Defining 'objects' on the simplest 
level
  > possible in the DTD and building up relationships in the instance
  document.
  >
  >
  > ------------------------------------------------------------------
------
  > IT Professionals: Match your unique skills with the best IT 
projects at
  > http://click.egroups.com/1/3381/1/_/809694/_/960825006/
  > ------------------------------------------------------------------
------
  >
  > To unsubscribe from this group, send an email to:
  > xpl-unsubscribe@o...
  >
  >
  >
  >



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



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

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., cagle@o... wrote:
I'm inclined to agree with you on the class issue. I've worried 
myself that
the class paradigm provides a number of limitations to what is 
essentially a
classless model. The problems with attempting to use an XML based 
code for a
procedural language are unfortunately pretty major, but most boil 
down to
Occam's razor -- is there any real benefit in coding a procedural 
language
in XML that can't already be done with DOM? I'd contend that there 
really
isn't -- most procedural languages work on one piece of  a data 
document at
a time, while XSL (as an example) tends to encourage a holistic 
approach to
coding: find the relevent patterns in an XML document and apply the
templates to the data. In this sense, the polymorphism that's done 
takes
place at the abstract level of designing the XSL templates rather 
than at
the object level.  I suppose that you could work a registration 
scheme such
that when an XML object with a recognized schema "entered the gate", 
so to
speak, only those XSL filters that recognized the schema would be 
considered
part of its methods, but again I think this falls into the square 
peg, round
hole issue.

I like to think that a better idea might be to associate with a 
document's
schema a URN that pointed to another XML document that contained the
interfaces and URLs of XSLT (XPL?) templates that could work on a 
given
document (or perhaps in turn another pointer document, a la 
Gnutella). Such
a registry document might also contain some kind of annotation 
element akin
to that found in the XML Schema language, so that an IDE could 
retrieve a
document, dereference its schema, dereference the templates document 
and
then display the results as an intellisense like drop-box.

I think this also opens up the possibility of polymorphism, 
declarative
style --  there is no reason that two documents with distinct schemas
couldn't reference the same set of templates (if the templates were 
general
enough) nor why you couldn't create a schema that pointed to both a 
base set
of templates and an augmented set for providing "subclassing" 
behavior.

We need to determine whether or not we're writing a procedural or
declarative language.  I think the idea of writing a general meta-
language
for programming is ill-advised. Programming languages vary across the 
board
from fairly simple scripted languages such as JavaScript to pointer 
driven
languages such as C++ (I shudder to think of a C++ language 
implementation
written in XML, to be honest) to text manipulation languages such as 
Perl.
Moreover, I think that each of these languages does what it does 
quite well,
and that it is far more difficult making from one linguistic 
namespace to
the next. Let's concentrate on extending what already exists, making 
XSLT
more robust, and developing an IDE that would work for such a 
solution.
After that we can reprogram the world <grin/>.

-- Kurt Cagle

----- Original Message -----
From: "Garreth Galligan" <garreth.galligan@o...>
To: <xpl@e...>
Sent: Monday, June 12, 2000 8:50 AM
Subject: Re: [XPL] The structure of classes in XPL


> When worlds collide, data architecture meets class architecture :)
> What's good for data: highly ridged, hierarchical and dependent 
structures
> is not necessarily good for a program.
>
> We are certainly staring right into the face of some very big and
> interesting contradictions:
>
>
> Alexander E. Gutman  wrote:
>
> >  As soon as XPL is closely related to XML, the structure
> >  of its classes should be as flexible as XML structures.
> >  Should we regard classes as XML element types
> >  (and, probably, declare them via schema element type definitions)
> >  or should we employ a standard approach of some kind?
>
> Just to muddy the waters further - Why Classes at all?
> Do Classes truly have any relevance to XML?
> Is XML and Classes a square peg in a round hole?
> Are we forcing OO paradigms on XML for paradigms' sake?
> I don't have the answers, just a lot of questions :)
>
> >  but I wonder if there is a solution close (in flexibility) to 
that of
XML
>
> I risk my neck and offer classless (no pun intended) object-based
languages
> (e.g. Self, JavaScript) as an alternative model which perhaps more 
closely
> mirror the flexibility and *simplicity* of XML. XML already offers 
many of
> the advantages of a class based system, e.g. encapsulation via 
namespaces.
>
> This is probably not the best example in the world to display 
prototyping,
> but:
>
> <occupation id="occupation1">
>     <title>mathematician</title>
>     <workplace>An Institute</workplace>
>     <alias>Some Guy</alias>
> </occupation>
>
> <occupation id="occupation2">
>     <title>programmer</title>
>     <workplace>A Company</workplace>
>     <alias>Some Guy</alias>
> </occupation>
>
>
> <me>
>     <human>
>         <name>Alexander Gutman</name>
>         <birthdate>1996-07-01</birthdate>
>     </human>
>     <prototype obj="occupation1">
>         <workplace>BlahBlah Institute</workplace>
>         <alias>Alex Goodman</alias>
>     </prototype>
>     <prototype obj="occupation2">
>         <alias>Alex Softman</alias>
>         <workplace>Foobar Software</workplace>
>         <prototype>
>             <description>My main job</description>
>         </prototype>
>     </prototype>
> </me>
>
> As you can see with the above we are looking at a much simpler DTD 
in
terms
> of structural relationships. Defining 'objects' on the simplest 
level
> possible in the DTD and building up relationships in the instance
document.
>
>
> --------------------------------------------------------------------
----
> IT Professionals: Match your unique skills with the best IT 
projects at
> http://click.egroups.com/1/3381/1/_/809694/_/960825006/
> --------------------------------------------------------------------
----
>
> To unsubscribe from this group, send an email to:
> xpl-unsubscribe@o...
>
>
>
>
--- End forwarded message ---

[exprla-devel] Re: [XPL] (unknown)

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

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
rod@c... wrote:

>  Hi, I just joined this list so I'm not clear about the goals or
> features of XPL. In any case, I joined this group to help me 
detemine
> whether XML could be used as a meta-language for representing
> programming languages.

Absolutely. If there is one agreed goal for XPL, this is it.

> I know XML can be used for defining languages
> for representing data. However, a programming language needs 
entities
> that are not included in a data representation language, such as
> variables. I know that XSLT has variables that could be used while
> transforming an XML doc. However, the XML doc doesn't have 
variables.
> Will XPL address this?

XPL will have to, no question.

At the moment, the best way to address the issue is to look at the 
XSLT
literature (I'm starting with www.w3.org/XML, myself), and try to see
how you would make XSLT variables serve the purpose.

Also, you might look into the archive for this group, for a post 
titled:

"[xpl] Variable = Container = Element ... = Directory?", 05/16/00.
That was my thoughts on what should be in XPL variables.

Thanks and welcome aboard

Jonathan
--- End forwarded message ---

[exprla-devel] (no subject)

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

--- In xpl-dev@y..., rod@c... wrote:
Hi, I just joined this list so I'm not clear about the goals or 
features of XPL. In any case, I joined this group to help me detemine 
whether XML could be used as a meta-language for representing 
programming languages. I know XML can be used for defining languages 
for representing data. However, a programming language needs entities 
that are not included in a data representation language, such as 
variables. I know that XSLT has variables that could be used while 
transforming an XML doc. However, the XML doc doesn't have variables. 
Will XPL address this? 

Rod
--- End forwarded message ---

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., "Garreth Galligan" <garreth.galligan@o...> wrote:
When worlds collide, data architecture meets class architecture :)
What's good for data: highly ridged, hierarchical and dependent 
structures
is not necessarily good for a program.

We are certainly staring right into the face of some very big and
interesting contradictions:


Alexander E. Gutman  wrote:

>  As soon as XPL is closely related to XML, the structure
>  of its classes should be as flexible as XML structures.
>  Should we regard classes as XML element types
>  (and, probably, declare them via schema element type definitions)
>  or should we employ a standard approach of some kind?

Just to muddy the waters further - Why Classes at all?
Do Classes truly have any relevance to XML?
Is XML and Classes a square peg in a round hole?
Are we forcing OO paradigms on XML for paradigms' sake?
I don't have the answers, just a lot of questions :)

>  but I wonder if there is a solution close (in flexibility) to that 
of XML

I risk my neck and offer classless (no pun intended) object-based 
languages
(e.g. Self, JavaScript) as an alternative model which perhaps more 
closely
mirror the flexibility and *simplicity* of XML. XML already offers 
many of
the advantages of a class based system, e.g. encapsulation via 
namespaces.

This is probably not the best example in the world to display 
prototyping,
but:

<occupation id="occupation1">
    <title>mathematician</title>
    <workplace>An Institute</workplace>
    <alias>Some Guy</alias>
</occupation>

<occupation id="occupation2">
    <title>programmer</title>
    <workplace>A Company</workplace>
    <alias>Some Guy</alias>
</occupation>


<me>
    <human>
        <name>Alexander Gutman</name>
        <birthdate>1996-07-01</birthdate>
    </human>
    <prototype obj="occupation1">
        <workplace>BlahBlah Institute</workplace>
        <alias>Alex Goodman</alias>
    </prototype>
    <prototype obj="occupation2">
        <alias>Alex Softman</alias>
        <workplace>Foobar Software</workplace>
        <prototype>
            <description>My main job</description>
        </prototype>
    </prototype>
</me>

As you can see with the above we are looking at a much simpler DTD in 
terms
of structural relationships. Defining 'objects' on the simplest level
possible in the DTD and building up relationships in the instance 
document.
--- End forwarded message ---

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote:
Kurt Cagle wrote:

> the schema defines the type and positional characteristics
> of an XML structure, but not any associated methods or
> events. However, you could make a superclass structure that
> might actually include a schema and an associated stylesheet
> with named templates, with templates acting as methods.

Hmm... Could you clarify this idea?
As far as I know, the output of a transformation procedure
is always an XML document/object and, furthermore, we cannot
perform any actions during transformation other than those
which reflect the output (probably, the "eval" XSL element can
produce some side-effects during transformation, I do not know).
So, how can an XSL template act as a method?
It seems that the only thing such a method can do
is returning an XML object. Do you mean that this object
is the body of the method? Or its return value?

Actually, I thought about methods and discovered another
possibility of associating a method with an element type:
via an attribute whose name is that of the method
and default value the method's body (or its identifier).
However, I am not quite sure that this is a good idea.

> As to the question of object polymorphism, it would probably
> be a safe assumption to say that an object is something that
> has a base level schema definition. XML Schema has a
> polymorphism mechanism that may be applicable here -- you
> could create a virtual schema for a human, then create
> another schema that inherits off the human schema for an
> occupational schema.

In available XSL documentation, I cannot find any
advanced possibilities of inheriting a schema.
What do you mean by inheriting a schema?
Copying the ancestor schema with subsequent extension?

> Note also that in the sample, you are
> confusing data and structure. Rather than:
[...]
> your structure could be changed to recognize that both
> mathematician and programmer are both occupations:
[...]

Of course, your structure is much better than mine.
However, my example was just an illustration of how
an XML structure can reflect the idea of multiple
class membership -- such an extremal polymorphism,
when an object can belong to several classes simultaneously
which are not connected via inheritance relations.
In your example, the object does not belong to several
classes, just to a single class, "human".

I am still thinking about XPL classes.
Suppose, they are XML element types.
(By the way, I do not suggest that all classes should
be element types. Probably, some of them could be so.)
Is it worth considering ANY element type as an XPL class?
Or should an element type meet some additional
requirements to be considered as an XPL class?
Is it worth exploiting XPath language in methods
or should the entire code be expressed via pure XML?
If any XML element type can be an XPL class,
what is the interface of such a class?
What does the language of methods' bodies look like?
What operators should it include?
Do we reinvent the DOM interface in this case?
Is it bad if we do so?

--
Alexander E. Gutman
--- End forwarded message ---

[exprla-devel] [xpl] Requirements for Discussion

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

--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
It's late at night, and I realize that the following needs serious
editing. Nonetheless, the intent should mostly be clear...

Requirements:


1. XPL will be a set of conventions for representing algorithms
  as XML documents.

  It will include conventions for representing algorithms of
  at least the following kinds:

  1.1  Tree-structured expressions, combining typed operands
       and operators.

  1.2  Procedural control-flow, including the standard loop
       and conditional constructions.

  1.3  Typed function calls, comprising "protocols" (OOP),
       i.e. "signatures" (abstract data types).

  1.4  Rule-based transformations of tree-structured expressions.

  1.5  Aggregation of function protocols into class interfaces.

  1.6  Aggregation of interfaces, to allow interface inheritance.

  1.7  Binding of external operations to formal XPL operations;
       e.g. callback functions activated from parsing.

  1.8  Regular expressions and EBNF grammars.

  1.9  Parsers implementing the recognition of regular expressions
       and grammars.

  1.10 Declaration of storage locations, with scope and lifetime
       determined by the decaring XPL program.

  1.11 Reference to storage locations by URLs or URIs.

  1.12 Generation of XPL elements by external events.

2. XPL will include a standard architecture for XPL parsers,
   and for XPL operations, which may be ported to any reasonable
   processing system.

3. XPL will be reflexive, i.e. self-descriptive

4. XPL will be developed in the context of, and following the
   example of, open standards for XML document handling, as
   documented in W3C/XML standards literature. Whenever a
   requirement can be completely met by the use of documented
   W3C/XML mechanisms, that use will be preferred to any other
   which entails mechanisms external to W3C/XML.

5. XPL will be developed under a recognized open-source charter,
   permitting access of official XPL sources to any party.
   Confidential sources will not be recognized as part of XPL.

6. The XPL architecture (yet to be defined) will include both
   interface definitions and their implementations. It will
   require that interfaces and implementation be defined in
   distinct documents, such that interfaces may be published
   independently of any implementation.

7. The XPL architecture will include both formal distributed
   processes, and processors on which they are to execute.
   It will require that formal and actual processors be defined
   in distinct documents, such that formal distributed processes
   may be published independently of how they will be mapped
   onto networks.

8. XPL will include XML documents which subsume existing interface
   definition schemes (such as COM, CORBA).

9. XPL will be developed subject to the goal of providing a means
   of programming for Web content, which is as simple and
   accessible as possble.

10. XPL documentation and tutorial materials will take special
    consideration of the requirements of the handicapped, the
    young, and non-English speakers.


Goodwill
Jonathan

When you're a chocolate frog, the universe is against you.
--- End forwarded message ---

[exprla-devel] Re: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., cagle@o... wrote:
There's a few differences I've encountered between object definitions 
in XML and the same definitions in a language like Java that might 
make overloading problematic.  The first is that an XML Schema 
definition is more like a VB type statement than a Java class -- the 
schema defines the type and positional characteristics of an XML 
structure, but not any associated methods or events. However, you 
could make a superclass structure that might actually include a 
schema and an associated stylesheet with named templates, with 
templates acting as methods. Keep in mind that the one primary 
difference between XML and procedural objects is that the XML 
instance of a schema may not necessarily be physically connected with 
the methods that operate on it. We should thus ask whether XPL works 
by keeping the XML instance data of a class as part of the object -- 
i.e., the XML acts as the local variables -- or the XML data arrives 
as input and is processed in real time against the XPL/XSLT templates 
(in which case the XPL objects are methods only). The former is a 
statist approach -- the data needs to be retained between calls, 
while the latter is stateless.

As to the question of object polymorphism, it would probably be a 
safe assumption to say that an object is something that has a base 
level schema definition. XML Schema has a polymorphism mechanism that 
may be applicable here -- you could create a virtual schema for a 
human, then create another schema that inherits off the human schema 
for an occupational schema.  Note also that in the sample, you are 
confusing data and structure. Rather than:

<me>
  <human>
    <name>Alexander Gutman</name>
    <birthdate>01.07.1966</birthdate>
  </human>
  <mathematician>
    <name>Alex Goodman</name>
    <workplace>Blahblah Institute</workplace>
  </mathematician>
  <programmer>
    <name>Alex Softman</name>
    <workplace>FoobarSoft</workplace>
  </programmer>
</me>

your structure could be changed to recognize that both mathematician 
and programmer are both occupations:

<me>
    <human>
          <name>Alexander Gutman</name>
          <birthdate>1996-07-01</birthdate>
          <occupation>
                <title>mathematician</title>
                <workplace>BlahBlah Institute</workplace>
                <alias>Alex Goodman</alias>
           </occupation>
          <occupation>
                <title>programmer</title>
                <workplace>Foobar Software</workplace>
                <alias>Alex Softman</alias>
           </occupation>
      </human>
</me>



-- Kurt Cagle
  ----- Original Message ----- 
  From: Richard Anthony Hein 
  To: xpl@e... 
  Sent: Sunday, June 11, 2000 10:51 AM
  Subject: RE: [XPL] The structure of classes in XPL


  Could a form of overloading address this problem?  Like in a Java 
class, there may be multiple functions in the class that do different 
things depending on the type of parameter (one may be a string, 
another may be an integer), but the overall function result is the 
same.  So if you use overloading, you call <human>, <mathematician>, 
and <programmer> as if they were different functions in the class?
   
  Richard A. Hein  

  -----Original Message-----
  From: Alexander E. Gutman [mailto:gutman@m...]
  Sent: June 11, 2000 10:15 AM
  To: xpl@e...
  Subject: [XPL] The structure of classes in XPL


    At this moment, I am thinking about how classes
    will be declared in XPL. And I encountered a problem.

    As soon as XPL is closely related to XML, the structure
    of its classes should be as flexible as XML structures.
    Should we regard classes as XML element types
    (and, probably, declare them via schema element type definitions)
    or should we employ a standard approach of some kind?

    Consider me as an example of an XPL object.
    First of all, I am a human.
    As a human, I have a name (Alexander Gutman)
    and birthdate (01.07.1966).
    On the other hand, I am a mathematician.
    As a mathematician, I have a name (Alex Goodman)
    and workplace (Blahblah Institute).
    Furthermore, I am also a programmer.
    As a programmer, I have a name (Alex Softman)
    and workplace (FoobarSoft).

    In XML, the above information can be easily structured,
    for instance, as follows:

    <me>
      <human>
        <name>Alexander Gutman</name>
        <birthdate>01.07.1966</birthdate>
      </human>
      <mathematician>
        <name>Alex Goodman</name>
        <workplace>Blahblah Institute</workplace>
      </mathematician>
      <programmer>
        <name>Alex Softman</name>
        <workplace>FoobarSoft</workplace>
      </programmer>
    </me>

    The question is:
    How such a structure can be modeled via "usual" classes?
    Of course, there are many different solutions, but I wonder
    if there is a solution close (in flexibility) to that of XML.
    (You may use any concepts, including multiple inheritance.)

    --
    Alexander E. Gutman

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

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




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



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

[exprla-devel] RE: [XPL] The structure of classes in XPL

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Could a form of overloading address this problem?  Like in a Java 
class,
there may be multiple functions in the class that do different things
depending on the type of parameter (one may be a string, another may 
be an
integer), but the overall function result is the same.  So if you use
overloading, you call <human>, <mathematician>, and <programmer> as 
if they
were different functions in the class?

Richard A. Hein

-----Original Message-----
From: Alexander E. Gutman [mailto:gutman@m...]
Sent: June 11, 2000 10:15 AM
To: xpl@e...
Subject: [XPL] The structure of classes in XPL


  At this moment, I am thinking about how classes
  will be declared in XPL. And I encountered a problem.

  As soon as XPL is closely related to XML, the structure
  of its classes should be as flexible as XML structures.
  Should we regard classes as XML element types
  (and, probably, declare them via schema element type definitions)
  or should we employ a standard approach of some kind?

  Consider me as an example of an XPL object.
  First of all, I am a human.
  As a human, I have a name (Alexander Gutman)
  and birthdate (01.07.1966).
  On the other hand, I am a mathematician.
  As a mathematician, I have a name (Alex Goodman)
  and workplace (Blahblah Institute).
  Furthermore, I am also a programmer.
  As a programmer, I have a name (Alex Softman)
  and workplace (FoobarSoft).

  In XML, the above information can be easily structured,
  for instance, as follows:

  <me>
    <human>
      <name>Alexander Gutman</name>
      <birthdate>01.07.1966</birthdate>
    </human>
    <mathematician>
      <name>Alex Goodman</name>
      <workplace>Blahblah Institute</workplace>
    </mathematician>
    <programmer>
      <name>Alex Softman</name>
      <workplace>FoobarSoft</workplace>
    </programmer>
  </me>

  The question is:
  How such a structure can be modeled via "usual" classes?
  Of course, there are many different solutions, but I wonder
  if there is a solution close (in flexibility) to that of XML.
  (You may use any concepts, including multiple inheritance.)

  --
  Alexander E. Gutman

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



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

[exprla-devel] The structure of classes in XPL

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

--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote:
At this moment, I am thinking about how classes
will be declared in XPL. And I encountered a problem.

As soon as XPL is closely related to XML, the structure
of its classes should be as flexible as XML structures.
Should we regard classes as XML element types
(and, probably, declare them via schema element type definitions)
or should we employ a standard approach of some kind?

Consider me as an example of an XPL object.
First of all, I am a human.
As a human, I have a name (Alexander Gutman)
and birthdate (01.07.1966).
On the other hand, I am a mathematician.
As a mathematician, I have a name (Alex Goodman)
and workplace (Blahblah Institute).
Furthermore, I am also a programmer.
As a programmer, I have a name (Alex Softman)
and workplace (FoobarSoft).

In XML, the above information can be easily structured,
for instance, as follows:

<me>
  <human>
    <name>Alexander Gutman</name>
    <birthdate>01.07.1966</birthdate>
  </human>
  <mathematician>
    <name>Alex Goodman</name>
    <workplace>Blahblah Institute</workplace>
  </mathematician>
  <programmer>
    <name>Alex Softman</name>
    <workplace>FoobarSoft</workplace>
  </programmer>
</me>

The question is:
How such a structure can be modeled via "usual" classes?
Of course, there are many different solutions, but I wonder
if there is a solution close (in flexibility) to that of XML.
(You may use any concepts, including multiple inheritance.)

--
Alexander E. Gutman
--- End forwarded message ---

[exprla-devel] RE: [XPL] About XPipes

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

--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Kurt, just to note some progress on the namespaces issue, 
www.xmlhack.com
has a submission on "Object Identifiers (OID) draft for unique URNs", 
which
you can read here:
http://www.ietf.org/internet-drafts/draft-mealling-oid-urn-00.txt  I 
have
read the introduction (I just found it), and it may help or hinder the
progress so far.  I am not sure if this is the solution to the 
namespace/uri
problem or not, but I haven't read it all yet.

Interesting stuff, looks good!

Richard A. Hein

-----Original Message-----
From: cagle@o... [mailto:cagle@o...]
Sent: June 11, 2000 5:07 AM
To: xpl@e...
Subject: [XPL] About XPipes


  About XML Pipes

  I recently wrote a case study for Wrox in which I started building 
an XSLT
framework called XPipes. It is intended as a framework for developing 
web
output quickly, although it incorporates a lot of what I've mentioned 
in
previous posts -- the double pass XSLT processing, the conversion of 
simple
tag/attribute elements into object requests, the definition of more
sophisticated scripts. It's still not simple enough, principally 
because of
namespace limitations, but it's getting there.

  For example, the following is a working XPipes page:
  <!-- sampleDoc.xml -->
  <xp:document xmlns:xp="http://www.vbxml.com/xp">
      <param name="title">My Document</param>
      <param name="author">Kurt Cagle</param>
      <param name="email">cagle@o...</param>
      <param name="user"/>
      <xp:script name="string" 
namespace="http://www.vbxml.com/string"/>
      <xp:body onclick="alert('This is a test!')">
          <h1><out>$title</out></h1>
          <h2><link href="mailto:
{$email}"><out>$author</out></link</h2>
  [Richard Anthony Hein]
  I like this method for output, it looks so intuitive to me, as far 
as XML
gets.

          <var name="sample_text"><p>Hello, #user, this is a sample 
of your
web page.</p></var>
          <out>string:replace_text($sample_text,'#user',$user)</out>
      </xp:body>
  </xp:document>

  If you then pass the following URL:

  http://localhost/xpserver.asp?source=sampleDoc&title=A New 
Page&user=John
Doe

  then the XP page, when doubly parsed will generate as output:

  <html>
      <head>
             <title>A New Page</title>
       </head>
      <body onclick="alert('This is a test!')">
          <h1>A New Page</h1>
          <h2><a href="mailto:cagle@o...">Kurt Cagle</h2>
          <p>Hello, John Doe, this is a sample of your web page.</p>
      </body>
  </html>

  It gets more complex than this -- I have tables, forms, and treeview
controls that all work within this paradigm as well -- but you get the
general idea.

  -- Kurt Cagle





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



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

[exprla-devel] About XPipes

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

--- In xpl-dev@y..., cagle@o... wrote:
About XML Pipes

I recently wrote a case study for Wrox in which I started building an 
XSLT framework called XPipes. It is intended as a framework for 
developing web output quickly, although it incorporates a lot of what 
I've mentioned in previous posts -- the double pass XSLT processing, 
the conversion of simple tag/attribute elements into object requests, 
the definition of more sophisticated scripts. It's still not simple 
enough, principally because of namespace limitations, but it's 
getting there.

For example, the following is a working XPipes page:
<!-- sampleDoc.xml -->
<xp:document xmlns:xp="http://www.vbxml.com/xp">
    <param name="title">My Document</param>
    <param name="author">Kurt Cagle</param>
    <param name="email">cagle@o...</param>
    <param name="user"/>
    <xp:script name="string" namespace="http://www.vbxml.com/string"/>
    <xp:body onclick="alert('This is a test!')">
        <h1><out>$title</out></h1>
        <h2><link href="mailto:{$email}"><out>$author</out></link</h2>
        <var name="sample_text"><p>Hello, #user, this is a sample of 
your web page.</p></var>
        <out>string:replace_text($sample_text,'#user',$user)</out>
    </xp:body>
</xp:document>

If you then pass the following URL:

http://localhost/xpserver.asp?source=sampleDoc&title=A New 
Page&user=John Doe

then the XP page, when doubly parsed will generate as output:

<html>
    <head>
           <title>A New Page</title>
     </head>
    <body onclick="alert('This is a test!')">
        <h1>A New Page</h1>
        <h2><a href="mailto:cagle@o...">Kurt Cagle</h2>
        <p>Hello, John Doe, this is a sample of your web page.</p>
    </body>
</html>

It gets more complex than this -- I have tables, forms, and treeview 
controls that all work within this paradigm as well -- but you get 
the general idea.

-- Kurt Cagle
--- End forwarded message ---

[exprla-devel] RE: [XPL] project suggestion

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

--- In xpl-dev@y..., "Tony Edgecombe" <tony.edgecombe@f...> wrote:
I have to agree with your comments on an IDE, for the last couple of 
years I
have been working with a product (www.formscape.com) which allows you 
to
build applications in a simple tree based drag and drop environment. 
I can
see a direct corellation between the structure of this tree and some 
of the
schemas talked about early on in this group. In this particular case 
the
software is focussed on formatted output but the principles could 
apply to
any type of application. The big benifit this allows is the 
configuration of
complex applications by non programmers (sometimes!) and very rapid
development because of the high level of abstraction.

It could be that this element of XPL is crucial to the adoption of the
language. XML is not the easiest thing to read or write when littered 
with
namespaces and attributes, anything but the simplist of programs 
could be
very frustating to construct.

Tony


  -----Original Message-----
  From: Richard Anthony Hein [mailto:935551@i...]
  Sent: 11 June 2000 07:34
  To: xpl@e...
  Subject: RE: [XPL] project suggestion


  Kurt,

  The message board sounds great.  I understand what you are saying 
about
building the architecture, and you are right.  I expect the component 
base
will grow quite quickly over time, once we have that architecture in 
place,
and so I concure.  I would like to hear more about XPipes ... what's 
it all
about - and XSLTalk, for that matter?

  When you say, "reduce everything down to the movement of streams" 
what
exactly do you mean?  I am not sure if you mean, don't worry about
performing operations on the streams?  Also, I am not sure what you 
mean
about emergent patterns ... am I right in thinking you mean to allow 
the
abstract architecture to handle the patterns which components follow 
in
providing parameters for input and output, location, etc ...?  Could 
you
clarify this a bit for me?

  Yes, XML is a web language ... but the web is going to be 
everything!
Let's take it slow and take care of the basics that XML excel in, 
yes, I can
see that, but let's also keep in mind the future, so that we can 
extend it.
I think making an extensible programming language isn't exactly 
easy ... we
have to think of scenarios that may be required in the future, and 
try to
plan for those eventualities.  You're right, we don't have to build 
it to
handle all the things that are and may decide come along ... it only 
means
we have to be careful, to allow us to extend it to handle the future 
demands
of the web.  So, I do agree, as long as we remember not to lock XPL 
in to
today's internet.  Let's build it for today, and leave room for 
tomorrow,
which XPL should do if the name means anything.

  My talk about an IDE is not asking the group to build one now.  It's
asking everyone to consider the idea that the IDE can be integrated 
into the
language itself and the total look and feel of the IDE should be 
linked to
the language in a way that hasn't been done before.  I can almost see 
it as
if when someone goes to start a new project in XPL, the IDE itself 
will
become the application - if it is something that can be visual.  So 
you
start with this bare IDE, and simply select components, and buttons 
and what
not, drop them where you want, and so on.  This sounds just like using
Visual Basic or something so far.  But if you take it a step further, 
then
the application is also an IDE to someone else ... you see?  Then the 
user
can change just about anything about the application, excepting 
perhaps the
code that runs the core logic.  Things like button type, input type 
can be
changed to the users liking, and what not.  Just like Mozilla can be a
browser and the editor for XML pages.  Of course, the authors of the
program, or administrators should also be able to limit that sort of 
thing
if necessary.

  I know we won't start by building the IDE, but what considerations 
do we
need to put into the language to make this easier to do later?  Is it
possible?  Does it make sense?  Do we need to put design 
considerations into
the language to support this, or will it work anyways?  Will XSLT do 
it all
for us?  These are questions running through my head.  The bottom 
line for
me, is it would be something wonderful to bring programming to the 
average
Joe.  Maybe not for programmers ... but still.  I hope XPL can do 
that.  So
anyways, before I write anymore, don't worry, I don't mean let's 
build an
IDE now (aside from me trying out an XSLT after we get the 
architecture and
syntax done - come on, it'd be fun!).  I just think it is something 
to think
about during the design of the language.  Others may disagree, and 
almost
certainly know a lot more than I do about this, so I defer to the 
better
judgement of my peers.  An article at www.xml.com about the "Semantic 
Web"
talks about this sort of thing though, and I was hoping we could get 
it to
happen for XPL.  Maybe the group could take a look at the article so 
they
can see where I am coming from with this idea?

  I agree with your third paragraph completely, although it might not 
seem
like it from the messages I have been sending.  I am just excited 
about the
possibilities! :-)  We absolutely must have the infrastructure, or 
else
nothing else I have been thinking about will ever work anyways!  So, 
let's
get the requirements together!  I have a few already, but I will send 
that
with the rest, when I get them sorted out.

  Thanks Kurt, for being patient (and the rest of XPLers)!  I have 
never
designed a language before, so bear with me and my far reaching (or 
fetched)
ideas about what it should do!

  Richard A. Hein



   -----Original Message-----
  From: cagle@o... [mailto:cagle@o...]
  Sent: June 11, 2000 12:01 AM
  To: xpl@e...
  Subject: Re: [XPL] project suggestion


    Richard,

    The requirements document sounds like a solid idea. Let me fill 
you in
on what I'm doing with VBXML -- Mark and I have talked about creating 
a new
site called XSLTalk, where we could set up a forum for handling
requirements.  I worked on a critical part of the XPipes framework 
today,
and may even be in a position in the next couple of days to set up 
message
boards where we could solicit requirements.  That way rather than 
trying to
sort things out in an arbitration process we can set up discussions in
something approaching real time.

    My personal druthers is to take the problem from the other 
direction --
define an architecture for integrating components on a generalized 
basis,
then add to the component base over time. Keep the language itself
relatively self contained, then move device functionality into 
components.
Reduce everything down to the movement of streams that are largely
transparent to device or file type. Abstract as much as possible --
parameters may come from SOAP or query strings or forms or anywhere 
else,
follow emergent patterns rather than provide specificity of code (not 
all
treeviews are created equal, even though the form is common to all).
Remember that XML is first and foremost a web language, and will not 
(and
should not) replace more complex compiled forms yet.  Move the 
language
slowly in that direction, of course, get people to start thinking 
about XML
as a language for handling compiled forms but focus on XMLs strengths 
before
extending the language to better handle its weaknesses.

    As I mentioned previously, I think an XML IDE is a cool idea, and 
should
be considered as a mechanism that could even be built using XPL, but 
I would
caution against concentrating on IDE too soon. In my mind the purpose 
of XPL
is to create an easy to use language that doesn't require a lot of
programming acument, that can be done using the native forms of XML 
without
a lot of exceptions, and that could be written in a text editor if 
need be.
It should be a language that allows for the intermingling of XML (or 
XSLT or
XPL), and that can be extended transparently. The ability to 
communicate
with devices, or handle MathML streams, or to toggle between HTML and 
WML
output should be considered as very much secondary to building a 
cohesive
infrastructure for working with components in the first place.

    I'll put together my requirements list on this and will see about
getting the XSLTalk website set up if that is what people are 
comfortable
with.

    -- Kurt

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



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