exprla-devel Mailing List for XPL: eXtensible Programming Language (Page 5)
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel — This is the Developers' list for the for XPL
You can subscribe to this list here.
| 2002 |
Jan
(198) |
Feb
(40) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:16:25
|
--- In xpl-dev@y..., Rod Moten <rod@c...> wrote: At 09:49 AM 6/20/00 +0000, Jonathan Burns wrote: > > Once we have an exact semantics for XPL, we're WAY ahead. To get this, >we really want an exact semantics for XPath, XSLT etc - because most of this >existing XML tech, we will want to reuse. What I'm hoping is that Groves >will be the absolute foundation for semantic definitions. Jonathan > > Phil Wadler has developed a formal semantics of XSLT. <a href="http://www.cs.bell-labs.com/who/wadler/papers/xsl-semantics/xsl- semant ics.pdf">xsl-semantics.pdf</a> <a href="http://www.cs.bell- labs.com/who/wadler/topics/xml.html">Walder's XML topics</a> Rod ******************************************** * Make affirming your wife a top priority. * ******************************************** --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:16:14
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Richard Anthony Hein wrote: > I am not sure on this yet, but maybe we can use the programs Paul > talked about in his article on Groves to do this. If you want to try > Rod, check out Jonathan's annotated Grove page. I'll take a look > too.Jonathan, what do you think?Richard A. Hein > > -----Original Message----- > From: Rod Moten [mailto:rod@c...] > Sent: June 19, 2000 1:37 PM > To: xpl@e... > Subject: [XPL] formal semantics of XSLT and other XML langs > Has anyone thought of developing a formal semantics, in > particular > operatational semantics, of XSLT and other XML languages? > The formal > semantics could be used to thoroughly analyze these > languages. From the > analysis, we may better understand what needs to go into XPL > to support the > other languages as well as overcome some of their > weaknesses. > > Rod > ******************************************** > * Make affirming your wife a top priority. * > ******************************************** > Oh yes indeed. Once we have an exact semantics for XPL, we're WAY ahead. To get this, we really want an exact semantics for XPath, XSLT etc - because most of this existing XML tech, we will want to reuse. What I'm hoping is that Groves will be the absolute foundation for semantic definitions. Jonathan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:15:59
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: I was wondering if it really would be possible to make a schema to describe an ISA in XML and use that during construction of a compiler for XPL, that can map XPL code to the ISA for a specific processor? Then if another ISA comes along, we can use XSLT to map the ISA to the XPL compiler specifically based on the new ISA's schema? Any thoughts? Am I totally off base here? Perhaps this is something like a Virtual Machine, except compiled, but we don't have to compile it. In addition, couldn't we use the same kind of technique for building an XPL I/O library, which maps perfectly to the instruction sets dealing with I/O? Maybe this is nonsense ... don't worry, just tell me, I have no real idea if it would work - it won't hurt my feelings. :-) Richard A. Hein --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:15:37
|
--- In xpl-dev@y..., cagle@o... wrote: Lucas, Welcome to our little universe here. It's still very much in the quark soup stage, but there are indications that light will break through any moment now. > My main working principle is that very large scale distributed > systems can't be programmed explicitly. Their behavior is emergent. > To get them to do useful things you have to look for existing > behaviors and use them as leverage. the converse is that you have to > forget about fixed specs except in well controlled subnets. I'm very much inclined to agree with you on that, although I would also caution that we have an existing paradigm that is nearly fifty years old now that works very much on the opposite approach -- that everything within a system must be designed from the bottom up, that a computer can't readily program itself (although that is essentially what any optimizing parser does) and that emergent behaviors are largely aberations to the system, rather than an expected characteristic of large scale distributed networks. Changing that mindset, while necessary, won't be easy. Emergent behavior engineering is still very much in its infancy, and is going to require that we start looking at programming as a holistic, rather than a reductionist problem. XML is a big part of that, because it inverts the emphasis that data has. In a reductionist mode, data is self- contained, discrete, a part of an object -- the sum of the data of a system is the sum of the data of its attendant parts. Reductionist programming works when the domain is small, but by its very nature is incapable of handling data that exists is a part of the environment, unless explicitly made aware of that data. Holistic programming on the other hand sees everything as data, with programs effectively being producers or consumers of that data -- organisms, if you will, albeit very low level ones, which live within the data environment. Reductionist components cannot evolve in the face of changing data requirements, and thus have to be sustained by very artificial constraints. Holistic data organisms, on the other hand, will likely need to evolve, but that means that the internal structures of those organisms may reach a point of complexity beyond that of people to understand. Moreover, such organisms themselves may be consumed. The one difference, however, between a biological and a cybernetic environment is that the principle constraints on a biological environment are energy based, while those in a cybernetic environment are time based. The implications of this are being worked out even now, but it does change the complexion of the environment considerably, cf. Vernor Vinge, among many others. > One of those behaviors is data clouds, which already exist in the > form of usenet messages, chain mail, viruses, etc. I believe that > this will not be a problem once intermediate nodes have detailed > control over what they pass through and why. Uncontrolled message > distribution like in Gnutella leads to big messes, but carefully > controlled message distribution should lead to clouds that are only > as > big as they need to be. Gnutella is actually an interesting model -- it takes advantage of the many to many relationships that the net has to offer. That it is currently used to distribute mp3s is fairly secondarily to the fact that it is a voluntary mechanism for creating an accessible network of resources without there needing to be an explicit concept of source. The refining of this concept will come over time -- as someone who inadvertantly ended up pinging every newsgroup in Usenet once (when Usenet itself was once smaller), I see Gnutella's notion as a harbinger of things to come. You access a local cloud, which can then work into ever increasing arcs of distribution, one local cloud at a time. > Another behavior is the mutation of protocols, because specialized > vocabularies are inevitable. Though worldOS nodes prefer their > native transport and message format, they can also have converters > for > other transports and formats. one immediate application for this > principle will be an adapter for 7-bit ascii. A 7 bit ascii device > can establish a relationship with a node that understands it, then > use > it as a gateway to nodes that don't understand 7 bit ascii. > > There are a couple ways that WorldOS might be useful to your projects > here. One is that it's a flexible app server which is not bound by > counterrevolutionary WWW thinking. You can plug in transports, > protocols, and functions fairly easily and not have to replicate that > code all over the place. Another is that it makes it pretty trivial > to work with xml. > > > Can't WorldOS make it impossible for someone to force me to go to > their site > > to buy, when I can exchange freely with whomever I wish and not be > > interfered with? > > you bet! vive la resistance! I'm currently working on an essay right now that talks about the fact that we are moving into a paradigm where bartering is not only possible, but will in fact be the primary economic transaction; moreover, that money, which is in essence a reputation marker issued by a government, will end up becoming subservient to reputation markers based upon more fungable standards, such as expertise, sex appeal (think about the rise of cyber-models), musical or literary talent, good deeds, and the like. As we end up entering into the cyber age, the distinctions between the real and the virtual world will continue to blur, I anticipate a point in the not too distance future where there really is no money in the traditional sense, where you can buy a weeks worth of groceries on the basis of a sonnet and a song, and where the primary assets of a country are measured in the number of cultural producers and not the amount of gold or weapons it has. That's the potential for XML, one that I foresee taking place in our lifetime (and perhaps helped along by this very group). -- Kurt Cagle > If there are any problems using the system for your projects let me > know. mailto:lucas@g... > > > > > -------------------------------------------------------------------- ---- > Wrox Wireless Developer Conference, Amsterdam, July 10-12. Choose from > 40+ technical sessions covering application of WAP, XML, ASP, Java and > C++ to mobile computing. Get your ticket to the future today! > http://click.egroups.com/1/5689/1/_/809694/_/961392229/ > -------------------------------------------------------------------- ---- > > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > > > --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:14:58
|
--- In xpl-dev@y..., cagle@o... wrote: Garreth, About the relationship between XSLT and XPL -- XSLT can be a pretty ugly language, but it's powerful -- I have an implementation of XPipes (my own XML based language) that actually works as a pre-processor to convert XPipes code to XSLT. Thus, I now have structures in my XPipes code like: <script name="str" source="http://www.xpl.com/cagle/namespace.asp? ns=str"/> <script name="table" source="http://www.xpl.com/cagle/namespace.asp?ns=table"/> <param name="cell" value="255"/> <function name="charTable" cell="$cell"> <table> <for var="i" start="0" end="128" by="1" test="$cell div 16 < $i" > <row> <for var="j" start="$i*16" end="$i*16+15" by="1"> <cell><eval>$j</eval></cell> <cell><eval>str:char($j)</cell> </for> </row> </for> </table> </function> This particular function creates a table of &#NN; characters, giving both the number and symbol of the character, 16 symbols per row. The cell parameter indicates how many cells should be created, and if exceeded (when divided by 16), causes the evaluation to stop. If you take out the brackets, this code becomes essentially the same as include str; function charTable($cell=255){ out('<table>'); for {$i=0;$i<=128 && cell/16<$i;$i++){ out('<row>'); for {$j=$i*16;$j<=$i*16+15;$j++){ out('<cell>',$j,'</cell>'); out('<cell>',str:char($j),'</cell>'); } } } However, there are some sizeable differences here even so, the biggest being that the resulting entity here is a text object, while in the context of XSLT it would be a table object, etc. The point about all of this is that XPipes is essentially a two pass XSLT entity -- the first pass converts the XPipes could (using XSLT) into XSLT, while the second actually applies the XSLT to a stub entity to handle parameterization of information. Indeed, in a number of cases, the XPath elements are mapped one to one into their XSLT representation: <if> becomes <xsl:if>, etc. The key to working with any XML based scripting language is to recognize that it must be XML based -- no additional notations beyond what already exists, a minimal (or non-existent) reliance on processing instructions (which are somewhat intractible solutions for transformations), no semi-colon delimited code blocks, etc. One of the primary requirements to me of an XPL should be that it should be possible to generate an XPL script through the application of an XSLT script (or by extension, an XPL script), while at the same time it should be possible to take an XPL script and similarly transform it into some other output (perhaps XML documentation, perhaps pretty printing, perhaps an interface query mechanism). In other words, XPL should be both in- and out- transformable. -- Kurt Cagle ----- Original Message ----- From: "Garreth Galligan" <garreth.galligan@o...> To: <xpl@e...> Sent: Monday, June 19, 2000 8:45 AM Subject: [XPL] Re: The structure of classes in XPL > Richard Anthony Hein wrote: > > >XPL doesn't need classes, but to make people comfortable we > >can make them using XPointer > > This is fascinating, but I'm afraid I'm not too up to speed with > XPointer. Do you know of any good reference material? W3C > documentation is a slow, tedious read. > > >Subject: [XPL] requirements > >3. XPL must be human readable. > > Agree with you absolutely, otherwise there would be no point in using > a markup language for the job. > > > Kurt Cagle wrote: > > >I think the idea of writing a general meta-language for > >programming is ill-advised > > With you on this one; if I'm right about your meaning in 'general > programming' as raised in some early posts which, more or less, > envisage XPL as storage/transfer/interface/whatever medium for > various existing languages. Great science, but a little too 'Star > Trek' for me right now. However I'm still on the side of XPL as > a 'meta-language' of sorts, for creating XPL based micro languages. > > >Let's concentrate on extending what already exists, > >making XSLT more robust, > > Well with you in the spirit of the concept, which is to use > applications of XPL for operation on other ML's. But it would take a > lot of persuading to get me over my innate dislike of XSLT. It's such > an *ugly* language, and is rooted in my mind as a tool for > publishingMLs most likely to be produced in a WYSIWYG application. > One needs to take a very deep breath before trying to hand code the > stuff. I'm inclined to think of XSLT as a round hole to XPL's square > peg, but then my experience with XSLT is hardly extensive and I'm > open to persuasion... > > > > > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > > > --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:14:46
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Any ideas about how to go about this Rod? Perhaps an example of how you think it would look is in order. A set of name-value pairs is what Groves do, and so perhaps this would be appropriate. It's a really good idea to do this, though, and I can see the benefits. Richard A. Hein -----Original Message----- From: Rod Moten [mailto:rod@c...] Sent: June 19, 2000 1:37 PM To: xpl@e... Subject: [XPL] formal semantics of XSLT and other XML langs Has anyone thought of developing a formal semantics, in particular operatational semantics, of XSLT and other XML languages? The formal semantics could be used to thoroughly analyze these languages. From the analysis, we may better understand what needs to go into XPL to support the other languages as well as overcome some of their weaknesses. Rod ******************************************** * Make affirming your wife a top priority. * ******************************************** ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:14:28
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: I am not sure on this yet, but maybe we can use the programs Paul talked about in his article on Groves to do this. If you want to try Rod, check out Jonathan's annotated Grove page. I'll take a look too. Jonathan, what do you think? Richard A. Hein -----Original Message----- From: Rod Moten [mailto:rod@c...] Sent: June 19, 2000 1:37 PM To: xpl@e... Subject: [XPL] formal semantics of XSLT and other XML langs Has anyone thought of developing a formal semantics, in particular operatational semantics, of XSLT and other XML languages? The formal semantics could be used to thoroughly analyze these languages. From the analysis, we may better understand what needs to go into XPL to support the other languages as well as overcome some of their weaknesses. Rod ******************************************** * Make affirming your wife a top priority. * ******************************************** ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:14:11
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: -----Original Message----- From: Garreth Galligan [mailto:garreth.galligan@o...] Sent: June 19, 2000 11:45 AM To: xpl@e... Subject: [XPL] Re: The structure of classes in XPL Richard Anthony Hein wrote: >XPL doesn't need classes, but to make people comfortable we >can make them using XPointer This is fascinating, but I'm afraid I'm not too up to speed with XPointer. Do you know of any good reference material? W3C documentation is a slow, tedious read. Not really at this point Gareth, I will look around though. My comment is probably not a good one anyways. I meant it in the sense that you can reference XML document nodes and fragments of nodes at any location, using XPath, and use XPointer to pick out the text/values of the nodes. So, from one XPL program we could make a reference to another, including that reference as if it were a class, and add our sub-class nodes to the mix without having to hand-code the superclass - the XML document that we reference. It doesn't seem to make sense to me to use classes in the sense people are used to. XPL should be able to allow people to mix together all kinds of XPL programs and XML documents, using XPath and XPointer. What's the sense in defining classes in the traditional sense? Really, it would be more like merging different sources together to build a new class, that can be defined as a sub-class or super-class. I hope I haven't confused you even more .... Well, I am not the best person for this anyways ... anyone with strong experience in OOP and a good overview of the XML related stuff would be a better person to go by. I have been doing a crash overview of various OOP languages and languages in general, and something like BETA, which uses "patterns" may be something more fitting to the structure of classes in XPL. I am not sure, but it's something to consider. We surely need to break away from Java and C++, however, if we want to really get an overview of what can be done, since these two don't really fit XPL in the ways we envision. BETA is a language that is different from Java and C++, but close enough to be understandable by people experienced with those two. Another is Prolog because Prolog and like languages are fitting for a distributed DATA model, with programs that are "free-ranging". For a better understanding of what I mean, take a look at Edd Dumbill's article at www.xml.com, on the "State of XML", where he goes into a lot of ideas about XML being used in a form of data cloud and programs (the XPL-Fog!) roam the web accessing data in XML via URIs. These ideas echo the ideas expressed by Jonathan, Kurt, and myself in our WorldOS postings. This all may be seem like side-tracking the issue, but really, to be able to use classes we need to get a grip on how classes might be defined in XML, so I think it's not a waste of time. Richard A. Hein To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:13:52
|
--- In xpl-dev@y..., Rod Moten <rod@c...> wrote: Has anyone thought of developing a formal semantics, in particular operatational semantics, of XSLT and other XML languages? The formal semantics could be used to thoroughly analyze these languages. From the analysis, we may better understand what needs to go into XPL to support the other languages as well as overcome some of their weaknesses. Rod ******************************************** * Make affirming your wife a top priority. * ******************************************** --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:13:24
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Thanks a lot Jonathan; this helps immensely. Some comments inline
follow....
-----Original Message-----
From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
Sent: June 19, 2000 9:29 PM
To: xpl@e...
Subject: Re: [xpl] Groves Annotated
Richard Anthony Hein wrote:
Great input Jonathan, once again. I wish I understood more than
half
of what you said.
Half's a start. The gist of it is fairly straightforward:
We must have a notation, to specify things.
When we're specifying data or programs, the notation is almost
always
text of some kind.
(Well, it could be done with tables or diagrams, but that's
uncommon.)
The notation is designed for TWO purposes: to be read by people,
and to
specify whatever it is.
We can almost always design the notation so that both purposes are
served conveniently.
The design of a notation is its syntax. The stuff it specifies is
the
semantics.
[Richard Anthony Hein]
I understood this much ...
It is usually possible to specify the stuff, and still have
considerable
room for manoeuvre in designing the semantics. This is nice, because
then we
can make the language more readable.
For instance, we can have white space and indenting.
But the semantics should be the same, regardless of syntactic
niceties
like whitespace.
Now it turns out that the official specification of XML specifies
the
syntax, only.
[Richard Anthony Hein]
I didn't actually realize this ...
We assume that parsing an XML document builds a tree structure
(that's
the semantics),
and usually it will, but the XML specification doesn't say that
it must.
This was also the case with SGML - and that caused confusion,
because
different development teams were intersted in different aspects of the
semantics.
It meant that different teams would build parsers differently,
and each
would be satisfied with the results - but they couldn't share working
code,
because they had built different styles of XML trees.
Groves was invented to standardize the semantics of SGML, so that
such
confusions couldn't arise.
It can do the same for XML, if need be.
Groves defines semantics only.
[Richard Anthony Hein]
This is a key point, and how simple it makes everything now that
you
have said it! I never grasped this out of Paul's paper. I had an
idea of
what Groves really meant, but it involved syntax as well, so this
clears all
that up and makes it all very clear to me!
The purpose of it is, to determine the properties of the elements
of
documents. Then there can be no question as to what XML files (that
is,
source files, in readable text) are supposed to represent.
Or to put it another way, there can be no question as to what an
XML
parser is supposed to build.
(There is a quibble, which can be confusing. In some cases, we
want our
programs to work on a semantics of characters, not tree elements. For
instance, parsers themselves. Their purpose is to create semantic
structures
according to the syntax of the source text. Therefore, their
implementations
must be programs using character and string semantics. Don't worry
about it,
it's a quibble.)
The intention is that XML syntax should be parsed so as to
produce trees
with precisely the semantics defined by the XML groves property sets.
Knowing this, confusion between XML syntax and XML semantics is
dispelled.
[Richard Anthony Hein]
Excellent.
Another thing that groves is good for, is defining alternative
versions
of a standard semantics, for different purposes. These versions are
the
alternative views, which Paul speaks of. Some applications only need
to know
about certain properties of (e.g.) XML trees, and can filter out the
rest,
for example.
Finally, since groves defines the semantics, groves can provide a
unique
semantic identification of every element in a document - an address.
To
define the semantics of a structure is to provide a complete
addressing
scheme for it.
So, groves are useful. Using them, we can state exactly what we
mean by
an XML document, exactly how to build it, and exactly how to identify
each
part of it.
The question I was keeping an eye on was, Is groves the ONLY
complete
description of XML semantics?
[Richard Anthony Hein]
Surely there are other ways, but they may just be reinventing
Groves,
like Paul mentions in his article. There may be a need to reinvent
Groves
for XPath, XPointer and XLink, but in the end it will probably retain
it's
fundamental nature, and end up looking pretty close to what it does
now.
Since XPath, XPointer and XLink are not finalized yet, it would be
beneficial to discuss this with the working groups, in their forums,
to find
out what they think about Groves, and how they see it relating to the
specs.
After all, up to a certain point, people were happy to use the
DOM -
which defines document semantics in terms of interfaces, made up of
operation declarations (method call formats) in IDL (Interface
Description
Language). Paul objects to the DOM because there is only one of it -
where
with groves, we can define many different interfaces (alternative
views).
I'm not sure we couldn't get a complete semantic definition, with
alternative DOMs, one for each view.
[Richard Anthony Hein]
But wouldn't this mean having more things to worry about? Groves
look
like they are one thing, while multiple DOMs sound like they would be
different, and require more knowledge, time and effort in order to
learn,
understand and implement. Perhaps I am wrong here, but why make
multiple
DOMs to describe something one method of creating Groves can do? I
can't
stand having 500 different ways to make an e-commerce site ... what a
pain
to try to figure out what technologies to even start with. I wish
there was
only one way that made sense - one of the reasons I went for XML ...
it is
one thing that describes all kinds of ways to do lots of things, but
if you
understand XML, you can understand all the others (in theory at
least).
But another candidate for a complete XML semantic definition is
XPath,
etc. There has been considerable progress with these since Paul wrote
his
article; by now, it may be that XPath can address everything in an XML
document that can be addressed; while XPointer can allow auxiliary
addressing schemes within documents, and XLinks can extend addressing
to
other documents.
[Richard Anthony Hein]
This is an important point ... better than making multiple DOMs I
think,
is to be able to use XPath, if it can do what Groves are supposed to
be able
to do. If anyone knows better than Jonathan and I about XPath and
Groves,
please speak up. If not ... let's go to the source.
Once Paul had gotten through an explanation of how groves are
constructed, I was convinced that they are indeed a complete semantic
description.
Futhermore, it is a description in very simple terms. Everything
you can
say about an XML document type can be defined in terms of name-value
pairs.
That means that if need be we can prove the correctness of the
programs we
write - and especially the basic XPL tags we define.
However, being low-level, it is also very tedious to read.
[Richard Anthony Hein]
True enough, name-value pairs is simple - it can't get much
simpler.
Tedious to read ... true, but wasn't that program Paul talked about
supposed
to document Groves automatically, since they are essentially
self-documenting? Besides which, C++ and Java are pretty tedious too
for
someone not used to it. Put together a self-documenting IDE for
Groves,
that documents the Grove (in a manner not unlike the link Paul gave)
you are
using on the fly in a side box, and it'll be easy enough. I think.
What I hope, is that XPath etc can eventually be defined in groves
terms, and show to be correct, and maybe also to be a complete
semantic
description. Because Xpath etc will usually be a much easier form to
read.
The more we can get all this straight in our heads, the more
effective
our discussions will be.
[Richard Anthony Hein]
Yep.
Enough for now
Jonathan
I also think that the newer XPath and other related
specifications may
do some of the things that we need for XPL, and I will do whatever
research
I can into these areas. Since Paul wrote in his article that comments
were
welcome, perhaps you should send him an email with a link back to your
annotations to his article. He would surely be able to help clear up
some
of the questions and concerns you bring up; maybe he'll even join the
group
(the author of WorldOS joined now, which is cool and a nice
surprise).You
wrote in your annotations that you have a lot of compiler
experience ... do
you have any suggested sources to look into to get a better idea about
compilers and even perhaps "how to make a computer language" type
information? :-) I still haven't a clue how you can make up a
syntax and
semantics, and build a compiler to translate it all to machine
language.
Don't you have to use an already existing language such as Assembly
or C to
do make the compiler? Probably a really stupid question, but I
transfered
out of computer science and into neuroscience (which would explain my
interest in your XPL-fog posts. I started CS with the intent to go
into a
neuroscience MS afterwards, hoping to work on neural networks and AI,
but I
switched into Nesc. early - I blame it all on my boring COBOL co-op
term and
all the really unhappy programmers working there), so I never got
that far.
:-(I will be going back to finish up that plan once I pay back the
money I
already owe, and save enough to go back to university.
Sincerely,Richard A.
Hein
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:13:01
|
--- In xpl-dev@y..., "Garreth Galligan" <garreth.galligan@o...> wrote: Richard Anthony Hein wrote: >XPL doesn't need classes, but to make people comfortable we >can make them using XPointer This is fascinating, but I'm afraid I'm not too up to speed with XPointer. Do you know of any good reference material? W3C documentation is a slow, tedious read. >Subject: [XPL] requirements >3. XPL must be human readable. Agree with you absolutely, otherwise there would be no point in using a markup language for the job. Kurt Cagle wrote: >I think the idea of writing a general meta-language for >programming is ill-advised With you on this one; if I'm right about your meaning in 'general programming' as raised in some early posts which, more or less, envisage XPL as storage/transfer/interface/whatever medium for various existing languages. Great science, but a little too 'Star Trek' for me right now. However I'm still on the side of XPL as a 'meta-language' of sorts, for creating XPL based micro languages. >Let's concentrate on extending what already exists, >making XSLT more robust, Well with you in the spirit of the concept, which is to use applications of XPL for operation on other ML's. But it would take a lot of persuading to get me over my innate dislike of XSLT. It's such an *ugly* language, and is rooted in my mind as a tool for publishingMLs most likely to be produced in a WYSIWYG application. One needs to take a very deep breath before trying to hand code the stuff. I'm inclined to think of XSLT as a round hole to XPL's square peg, but then my experience with XSLT is hardly extensive and I'm open to persuasion... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:12:41
|
--- In xpl-dev@y..., "Garreth Galligan" <garreth.galligan@o...> wrote: Jonathan Burns wrote: > Don't split the group. Why, have you decided in what direction the group is going to proceed? ;) Working on an application of XPL while work on XPL is ongoing is not entirely without merit. After all many of us(through our own admission) lack experience with the new XML techs and we can hardly professes to build the architecture of XPL's 'house' when we've never so much as place one brick upon another. Even if the job was abortive, experience is never wasted... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:12:22
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Richard Anthony Hein wrote: > Great input Jonathan, once again. I wish I understood more than half > of what you said. > > > > Half's a start. The gist of it is fairly straightforward: > > We must have a notation, to specify things. > > When we're specifying data or programs, the notation is almost always > text of some kind. > (Well, it could be done with tables or diagrams, but that's uncommon.) > > The notation is designed for TWO purposes: to be read by people, and > to specify whatever it is. > We can almost always design the notation so that both purposes are > served conveniently. > The design of a notation is its syntax. The stuff it specifies is the > semantics. > > It is usually possible to specify the stuff, and still have > considerable room for manoeuvre in designing the semantics. This is > nice, because then we can make the language more readable. > For instance, we can have white space and indenting. > > But the semantics should be the same, regardless of syntactic niceties > like whitespace. > > > Now it turns out that the official specification of XML specifies the > syntax, only. > > We assume that parsing an XML document builds a tree structure (that's > the semantics), > and usually it will, but the XML specification doesn't say that it > must. > > This was also the case with SGML - and that caused confusion, because > different development teams were intersted in different aspects of the > semantics. > It meant that different teams would build parsers differently, and > each would be satisfied with the results - but they couldn't share > working code, because they had built different styles of XML trees. > > Groves was invented to standardize the semantics of SGML, so that such > confusions couldn't arise. > > It can do the same for XML, if need be. > > > Groves defines semantics only. > > The purpose of it is, to determine the properties of the elements of > documents. Then there can be no question as to what XML files (that > is, source files, in readable text) are supposed to represent. > Or to put it another way, there can be no question as to what an XML > parser is supposed to build. > > (There is a quibble, which can be confusing. In some cases, we want > our programs to work on a semantics of characters, not tree elements. > For instance, parsers themselves. Their purpose is to create semantic > structures according to the syntax of the source text. Therefore, > their implementations must be programs using character and string > semantics. Don't worry about it, it's a quibble.) > > The intention is that XML syntax should be parsed so as to produce > trees with precisely the semantics defined by the XML groves property > sets. Knowing this, confusion between XML syntax and XML semantics is > dispelled. > > > Another thing that groves is good for, is defining alternative > versions of a standard semantics, for different purposes. These > versions are the alternative views, which Paul speaks of. Some > applications only need to know about certain properties of (e.g.) XML > trees, and can filter out the rest, for example. > > Finally, since groves defines the semantics, groves can provide a > unique semantic identification of every element in a document - an > address. To define the semantics of a structure is to provide a > complete addressing scheme for it. > > > So, groves are useful. Using them, we can state exactly what we mean > by an XML document, exactly how to build it, and exactly how to > identify each part of it. > > The question I was keeping an eye on was, Is groves the ONLY complete > description of XML semantics? > > After all, up to a certain point, people were happy to use the DOM - > which defines document semantics in terms of interfaces, made up of > operation declarations (method call formats) in IDL (Interface > Description Language). Paul objects to the DOM because there is only > one of it - where with groves, we can define many different interfaces > (alternative views). I'm not sure we couldn't get a complete semantic > definition, with alternative DOMs, one for each view. > > But another candidate for a complete XML semantic definition is XPath, > etc. There has been considerable progress with these since Paul wrote > his article; by now, it may be that XPath can address everything in an > XML document that can be addressed; while XPointer can allow auxiliary > addressing schemes within documents, and XLinks can extend addressing > to other documents. > > > Once Paul had gotten through an explanation of how groves are > constructed, I was convinced that they are indeed a complete semantic > description. > > Futhermore, it is a description in very simple terms. Everything you > can say about an XML document type can be defined in terms of > name-value pairs. That means that if need be we can prove the > correctness of the programs we write - and especially the basic XPL > tags we define. > > However, being low-level, it is also very tedious to read. > > What I hope, is that XPath etc can eventually be defined in groves > terms, and show to be correct, and maybe also to be a complete > semantic description. Because Xpath etc will usually be a much easier > form to read. > > > The more we can get all this straight in our heads, the more effective > our discussions will be. > > Enough for now > > Jonathan > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I also think that the newer XPath and other related specifications may > do some of the things that we need for XPL, and I will do whatever > research I can into these areas. Since Paul wrote in his article that > comments were welcome, perhaps you should send him an email with a > link back to your annotations to his article. He would surely be able > to help clear up some of the questions and concerns you bring up; > maybe he'll even join the group (the author of WorldOS joined now, > which is cool and a nice surprise).You wrote in your annotations that > you have a lot of compiler experience ... do you have any suggested > sources to look into to get a better idea about compilers and even > perhaps "how to make a computer language" type information? :-) I > still haven't a clue how you can make up a syntax and semantics, and > build a compiler to translate it all to machine language. Don't you > have to use an already existing language such as Assembly or C to do > make the compiler? Probably a really stupid question, but I > transfered out of computer science and into neuroscience (which would > explain my interest in your XPL-fog posts. I started CS with the > intent to go into a neuroscience MS afterwards, hoping to work on > neural networks and AI, but I switched into Nesc. early - I blame it > all on my boring COBOL co-op term and all the really unhappy > programmers working there), so I never got that far. :-(I will be > going back to finish up that plan once I pay back the money I already > owe, and save enough to go back to university. Sincerely,Richard A. > Hein > --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:11:54
|
--- In xpl-dev@y..., Lucas Gonze <lucas@g...> wrote: Thanks, Richard! Mark's comment on how small this world is is right on - I ran into him a few days ago on vbxml. I'm looking forward to seeing how the group develops. On a related topic, I have been working on xml config files. the files are just clumps of xml messages calling function handlers in your local worldOS node. after the third or fourth one it became clear that I was clumsily writing a program in xml. ...so the idea of an xml language is not uncool by any means. - Lucas > Richard Anthony Hein wrote: > > Welcome to the group Lucas! Or is it Mr. Lucas? > > It was only about a week and a half ago that I came across > WorldOS ... it's still strange to me to see how small the world > is, as Mark Wilson noted in an earlier post! To think that we > made a connection through a brand-spanking-new site, > shouldexist.org ... it's just amazing! > > I hope you stay to work with the group in the future, and we'll > see what "emerges". It seems like we are gathering a nice pool > of talented people, with me being the least among you all. Ah, > it reminds me of something I heard somewhere; "if you want to > be great, surround yourself with greatness". Not that I want > to be great ... yeah, ok, I do. ;-) > > More comments will follow concerning the meat of your post, as > soon as I figure it out. > > Sincerely, > > Richard A. Hein > > -----Original Message----- > From: lucas@g... [mailto:lucas@g...] > Sent: June 19, 2000 1:24 AM > To: xpl@e... > Subject: [XPL] Re: [xpl-fog] To the Back Burner > > Eric Hanson of shouldexist.org clued me in on the > discussion > happening here. speaking as the author of WorldOS, I > think that our > projects are after the same thing. I'm happy to > discover this group. > some thoughts that I hope are relevant: > > My main working principle is that very large scale > distributed > systems can't be programmed explicitly. Their > behavior is emergent. > To get them to do useful things you have to look for > existing > behaviors and use them as leverage. the converse is > that you have to > forget about fixed specs except in well controlled > subnets. > > One of those behaviors is data clouds, which already > exist in the > form of usenet messages, chain mail, viruses, etc. I > believe that > this will not be a problem once intermediate nodes > have detailed > control over what they pass through and why. > Uncontrolled message > distribution like in Gnutella leads to big messes, > but carefully > controlled message distribution should lead to clouds > that are only > as > big as they need to be. > > Another behavior is the mutation of protocols, > because specialized > vocabularies are inevitable. Though worldOS nodes > prefer their > native transport and message format, they can also > have converters > for > other transports and formats. one immediate > application for this > principle will be an adapter for 7-bit ascii. A 7 > bit ascii device > can establish a relationship with a node that > understands it, then > use > it as a gateway to nodes that don't understand 7 bit > ascii. > > There are a couple ways that WorldOS might be useful > to your projects > here. One is that it's a flexible app server which > is not bound by > counterrevolutionary WWW thinking. You can plug in > transports, > protocols, and functions fairly easily and not have > to replicate that > code all over the place. Another is that it makes it > pretty trivial > to work with xml. > > > Can't WorldOS make it impossible for someone to > force me to go to > their site > > to buy, when I can exchange freely with whomever I > wish and not be > > interfered with? > > you bet! vive la resistance! > > If there are any problems using the system for your > projects let me > know. mailto:lucas@g... > > ----------------------------------------------------- > ----------------------------------------------------- > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > --------------------------------------------------------------- > > --------------------------------------------------------------- > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... -- L.U.C.A.S.: Lifeform Used for Calculation and Accurate Sabotage --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:11:34
|
--- In xpl-dev@y..., "Michael Lauzon" <ce940@f...> wrote: Jonathan, I'm not spliting the group, it's the same group, working on the same thing; XPL & XPLScript are the same...one is web-based (XPLScript) that incorporates XHTML. And the other is for major programming, if it can be said that way. :) To respond about Miva, it is not only for eCommerce, there are search engines built with it, chat sites, guest books, web-based email and what have you not. Same with Cold Fusion, as well as Tango. But, I will take your suggestion, about doing a write up on each of these, though it might take me a while as I have a summer JOB (Just Over Broke). --- In xpl@e..., Jonathan Burns <saski@w...> wrote: > Michael Lauzon 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. Comments, please?! > > > > Now that I've got a draft of the Groves stuff done, I can attend to > this. > > I've taken a look at Miva - at least, it has a few tags for arithmetic > operations. > Proof of concept. > > I've scanned Allaire's Cold Fusion website, and that's about it. "70 > tags!" is all > that sticks in my mind. Well, you can build a pretty big universe with > 70 elements - > look what we do with 91! > > Tango, I haven't even looked. > > > Now let me be frank. I couldn't care less about Miva - and I couldn't > care less > about e-commerce as a whole. Cold Fusion is a target worth shooting at - > but > I have no desire to spend a couple of years developing the user service > base > which is an indispensable part of providing a system as widespread as > Cold > Fusion. > > What I do care about is clarity in technical understanding. I've been > around - > I've seen that the concepts underlying software are not that hard - and > I'm > utterly dismayed at the black boxes around systems which deny the > comprehension > of the curious, and the unreadable academese which passes for > documenation, > and the invention of overlapping jargons by specialists; and the > combined effect > that all of these have, of making it look hard. > > XML is a rare opportunity to start afresh. It's a chance to get a > thousand data formats > away from their host platforms, review them, analyse them down to their > base concepts, > unify them, and make the resulting simplified data language as plain as > day. So that > anyone can get all they need to know about data representation and > processing, > from one source, with appropriately little effort. > > So that there will be no more "must have two years experience in this > buzzword we > first heard last week" shit. No more obscurantism, no more > quasi-elitism. Just simple > principles for putting things together and making them work. > > > XPL is my best chance to do just that. > > My success with the group is something I measure by the comprehension I > can > convey - to the eventual users of XPL, but meantime to people like Ali > and Richard > with high intelligence and curiosity but maybe without the background. > And likewise, > what I can learn from experienced practitioners like Kurt. > > To do this, it is necessary to get down to the basics, and bring them up > to the focus > of discussion. That's why, while jobless leisure permits me, I am > getting my head > around XPath and XPointers and CSS and XSLT and Groves, as fast as I > possibly > can. Then I will be able to say: "If we design our languages this way, > then they > will let us do that." > > The result of a few of us doing so, I am fairly confident, will be that > we can indeed > create formats and processing languages for any purpose. Including the > duplication > of Cold Fusion functionality, if we want. > > The long way round will be the shortest - because we'll be doing it with > undertanding, > every step. > > So I think, that the shortest way to get to XPLScript as you conceive it > will be, if you > investigate Miva and Cold Fusion and Tango in detail - and write up what > you find - > and tell us what you find. Because some of us will have our strengths in > conceiving > applications - and some in defining basic mechanisms. > > Don't split the group. > > Give us the benefits of your application-level knowledge. > > That way we share our strengths, while each one is free to exert his/her > own to > the fullest. > > Sincerely > Jonathan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:11:13
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Michael Lauzon 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. Comments, please?! > Now that I've got a draft of the Groves stuff done, I can attend to this. I've taken a look at Miva - at least, it has a few tags for arithmetic operations. Proof of concept. I've scanned Allaire's Cold Fusion website, and that's about it. "70 tags!" is all that sticks in my mind. Well, you can build a pretty big universe with 70 elements - look what we do with 91! Tango, I haven't even looked. Now let me be frank. I couldn't care less about Miva - and I couldn't care less about e-commerce as a whole. Cold Fusion is a target worth shooting at - but I have no desire to spend a couple of years developing the user service base which is an indispensable part of providing a system as widespread as Cold Fusion. What I do care about is clarity in technical understanding. I've been around - I've seen that the concepts underlying software are not that hard - and I'm utterly dismayed at the black boxes around systems which deny the comprehension of the curious, and the unreadable academese which passes for documenation, and the invention of overlapping jargons by specialists; and the combined effect that all of these have, of making it look hard. XML is a rare opportunity to start afresh. It's a chance to get a thousand data formats away from their host platforms, review them, analyse them down to their base concepts, unify them, and make the resulting simplified data language as plain as day. So that anyone can get all they need to know about data representation and processing, from one source, with appropriately little effort. So that there will be no more "must have two years experience in this buzzword we first heard last week" shit. No more obscurantism, no more quasi-elitism. Just simple principles for putting things together and making them work. XPL is my best chance to do just that. My success with the group is something I measure by the comprehension I can convey - to the eventual users of XPL, but meantime to people like Ali and Richard with high intelligence and curiosity but maybe without the background. And likewise, what I can learn from experienced practitioners like Kurt. To do this, it is necessary to get down to the basics, and bring them up to the focus of discussion. That's why, while jobless leisure permits me, I am getting my head around XPath and XPointers and CSS and XSLT and Groves, as fast as I possibly can. Then I will be able to say: "If we design our languages this way, then they will let us do that." The result of a few of us doing so, I am fairly confident, will be that we can indeed create formats and processing languages for any purpose. Including the duplication of Cold Fusion functionality, if we want. The long way round will be the shortest - because we'll be doing it with undertanding, every step. So I think, that the shortest way to get to XPLScript as you conceive it will be, if you investigate Miva and Cold Fusion and Tango in detail - and write up what you find - and tell us what you find. Because some of us will have our strengths in conceiving applications - and some in defining basic mechanisms. Don't split the group. Give us the benefits of your application-level knowledge. That way we share our strengths, while each one is free to exert his/her own to the fullest. Sincerely Jonathan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:10:47
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Welcome to the group Lucas! Or is it Mr. Lucas? It was only about a week and a half ago that I came across WorldOS ... it's still strange to me to see how small the world is, as Mark Wilson noted in an earlier post! To think that we made a connection through a brand-spanking-new site, shouldexist.org ... it's just amazing! I hope you stay to work with the group in the future, and we'll see what "emerges". It seems like we are gathering a nice pool of talented people, with me being the least among you all. Ah, it reminds me of something I heard somewhere; "if you want to be great, surround yourself with greatness". Not that I want to be great ... yeah, ok, I do. ;-) More comments will follow concerning the meat of your post, as soon as I figure it out. Sincerely, Richard A. Hein -----Original Message----- From: lucas@g... [mailto:lucas@g...] Sent: June 19, 2000 1:24 AM To: xpl@e... Subject: [XPL] Re: [xpl-fog] To the Back Burner Eric Hanson of shouldexist.org clued me in on the discussion happening here. speaking as the author of WorldOS, I think that our projects are after the same thing. I'm happy to discover this group. some thoughts that I hope are relevant: My main working principle is that very large scale distributed systems can't be programmed explicitly. Their behavior is emergent. To get them to do useful things you have to look for existing behaviors and use them as leverage. the converse is that you have to forget about fixed specs except in well controlled subnets. One of those behaviors is data clouds, which already exist in the form of usenet messages, chain mail, viruses, etc. I believe that this will not be a problem once intermediate nodes have detailed control over what they pass through and why. Uncontrolled message distribution like in Gnutella leads to big messes, but carefully controlled message distribution should lead to clouds that are only as big as they need to be. Another behavior is the mutation of protocols, because specialized vocabularies are inevitable. Though worldOS nodes prefer their native transport and message format, they can also have converters for other transports and formats. one immediate application for this principle will be an adapter for 7-bit ascii. A 7 bit ascii device can establish a relationship with a node that understands it, then use it as a gateway to nodes that don't understand 7 bit ascii. There are a couple ways that WorldOS might be useful to your projects here. One is that it's a flexible app server which is not bound by counterrevolutionary WWW thinking. You can plug in transports, protocols, and functions fairly easily and not have to replicate that code all over the place. Another is that it makes it pretty trivial to work with xml. > Can't WorldOS make it impossible for someone to force me to go to their site > to buy, when I can exchange freely with whomever I wish and not be > interfered with? you bet! vive la resistance! If there are any problems using the system for your projects let me know. mailto:lucas@g... ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:10:37
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Great input Jonathan, once again. I wish I understood more than half of what you said. I also think that the newer XPath and other related specifications may do some of the things that we need for XPL, and I will do whatever research I can into these areas. Since Paul wrote in his article that comments were welcome, perhaps you should send him an email with a link back to your annotations to his article. He would surely be able to help clear up some of the questions and concerns you bring up; maybe he'll even join the group (the author of WorldOS joined now, which is cool and a nice surprise). You wrote in your annotations that you have a lot of compiler experience ... do you have any suggested sources to look into to get a better idea about compilers and even perhaps "how to make a computer language" type information? :-) I still haven't a clue how you can make up a syntax and semantics, and build a compiler to translate it all to machine language. Don't you have to use an already existing language such as Assembly or C to do make the compiler? Probably a really stupid question, but I transfered out of computer science and into neuroscience (which would explain my interest in your XPL-fog posts. I started CS with the intent to go into a neuroscience MS afterwards, hoping to work on neural networks and AI, but I switched into Nesc. early - I blame it all on my boring COBOL co-op term and all the really unhappy programmers working there), so I never got that far. :-( I will be going back to finish up that plan once I pay back the money I already owe, and save enough to go back to university. Sincerely, Richard A. Hein -----Original Message----- From: me@m... [mailto:me@m...]On Behalf Of Jonathan Burns Sent: June 18, 2000 11:44 PM To: xpl@e... Subject: [xpl] Groves Annotated I've just finished a review of Paul Prescod's Addressing the Enterprise: Why the Web needs Groves, as an annotated version of the original document. It's up on my homepage - here's the URL. Once I've done some further investigation and amended the thing, I'd like to pass it to XML-DEV, and see who bites. Jonathan ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:10:19
|
--- In xpl-dev@y..., lucas@g... wrote: Eric Hanson of shouldexist.org clued me in on the discussion happening here. speaking as the author of WorldOS, I think that our projects are after the same thing. I'm happy to discover this group. some thoughts that I hope are relevant: My main working principle is that very large scale distributed systems can't be programmed explicitly. Their behavior is emergent. To get them to do useful things you have to look for existing behaviors and use them as leverage. the converse is that you have to forget about fixed specs except in well controlled subnets. One of those behaviors is data clouds, which already exist in the form of usenet messages, chain mail, viruses, etc. I believe that this will not be a problem once intermediate nodes have detailed control over what they pass through and why. Uncontrolled message distribution like in Gnutella leads to big messes, but carefully controlled message distribution should lead to clouds that are only as big as they need to be. Another behavior is the mutation of protocols, because specialized vocabularies are inevitable. Though worldOS nodes prefer their native transport and message format, they can also have converters for other transports and formats. one immediate application for this principle will be an adapter for 7-bit ascii. A 7 bit ascii device can establish a relationship with a node that understands it, then use it as a gateway to nodes that don't understand 7 bit ascii. There are a couple ways that WorldOS might be useful to your projects here. One is that it's a flexible app server which is not bound by counterrevolutionary WWW thinking. You can plug in transports, protocols, and functions fairly easily and not have to replicate that code all over the place. Another is that it makes it pretty trivial to work with xml. > Can't WorldOS make it impossible for someone to force me to go to their site > to buy, when I can exchange freely with whomever I wish and not be > interfered with? you bet! vive la resistance! If there are any problems using the system for your projects let me know. mailto:lucas@g... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:10:04
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: I've just finished a review of Paul Prescod's Addressing the Enterprise: Why the Web needs Groves, as an annotated version of the original document. It's up on my homepage - here's the URL. Once I've done some further investigation and amended the thing, I'd like to pass it to XML-DEV, and see who bites. Jonathan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:09:44
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: XPL-fog eh? Cool .... free-floating object g ... groves? Don't try to put the genie back in the bottle, Jonathan, someone else will just open it. It's obvious there has got to be a great deal of thought put into this concept. I think this must be like physicists felt when they knew that fission was possible, and started to try to really make it happen. The consequences were both terrible and wonderful. The conflict must have been intense for anyone who wasn't/isn't a sociopath. However, this is a tool. This isn't a god, this isn't consciousness, it isn't awareness. It may be thought. But animals think. We use animals to carry burdens, help with work, and we eat them. They are tools for survival. People who worship animals, or use them in evil ways have lost sight of what animals are. Even pets are tools, although we often love them. They are there for us, to serve us. We don't serve them. Computers are tools, and people are losing sight of the fact that we created computers, and not the other way around. Computers now are things that people depend on to exist. Y2K proved that feeling ran through our society. It's sad. If all the computers shut down over night across the world, it's our own stupidity if we end up screwed. There is no reason on Earth ... maybe in space there is, but not here ... to depend on computers for survival. Food still grows, and computers don't make them grow ... they are sometimes used as tools to help food grow, but that's all. Oil flowed before computers, rain fell, the sun turned and the world survived without computers. Now, with the stock market being the god of man - just look at CNN, the majority of news is numbers, and more numbers, relating to computer stuff, internet, and money, money, money. It's disgusting. "Oh, oh, what are we going to do ... Microsoft is in trouble ... oh, oh, boo hoo, my email program might not work in 3 years when someone in Japan sends me email ... boo hoo, I'll lose money ...", yeah, right. Like Outlook is the only email program and no other email program supports the message format you use ... people are ignorant. They listen to their priests of technology, even 'evangelists', who know the deep magic of computing, and they obey. They are torn between the multiple religions of technology; we have Sun worshippers, and MS worshippers, and Oracle worshippers. I can imagine a future, when artificial intelligence beings - the Sun, the Oracle, tell people how to run their lives, and people worship them, bringing offerings to them to continue in their grace. As long as the stock market rises, everything is just peachy, and they'll obey. In a future where software is proprietary, this can happen, because no one understands it, or how to make it. It will become magic, in the truest sense of the word, controlled by the priesthood of computer science. The question is, can we not make XPL and this XPL fog concept open and free? Can't WorldOS make it impossible for someone to force me to go to their site to buy, when I can exchange freely with whomever I wish and not be interfered with? Can't we encrypt vital information, and make connections that are broken as quickly as they are formed, so people can't catch my information in transit? Not unless we keep it out of the hands of Sun, MS, AOL, Time Warner, and all these media and money making companies. It has to be open source, and available. If we don't build it, then I assure you, they will. I watched the keynote address by Scott McNealy of Sun, at JavaOne, and the number of times that he, and other people on stage with him said "you'll make tons of MONEY!!!!", was absolutely frightening. At many points when Sun yelled out it's motto, people in the audience gave reluctant applause. One woman speaking said, something along the lines of, "what, money doesn't excite you? Who wants to make lots of MONEY?!", and again weak applause, showing just how many people see through this guise to what it really is: love and worship of money. Why am I rambling on, you might ask. Because this is about fighting a system. It's about taking countermeasures in a war against greed, love of power, and loss of freedom. If this whole vision means slavery for people, then it's not good. But the end result will come from people, not from the technology. The potential for helping people and increasing knowledge of good is just as possible as the potential for making people slaves and increasing the knowledge of evil in the world. The question is, will we allow those kinds of people, who worship money and numbers and power, to take this potentiality and use it for their purposes, in closed, proprietary purposes? I know I am thinking the way that a lot of people are thinking, even though to come right out and say it may sound alarmist. However, like Kurt said, we have reached the point where moral issues relating to these ideas need to be addressed. Critical mass is reached in the consciousness of humanity, saying, what will this do to us as humans, and how do we stop people from using all this power against us? Critical mass is also reached in humanity, saying, what can we do to humans, and how to we use our power against humans to take their lives away, and force them to make our numbers get bigger, that intangible, made up stuff called money today, that has no standard and base within reality - where a software company is worth millions, but a farm is worth thousands. Where seeds can be patented, and genetic sequences sold to the highest bidder? Like Einstein, who must have had some conflict because of his great contributions to physics, and who lived a life of a pacifist, we all together must be peaceful, and yet, like him, at the breaking of WWII, must say, now we need to build a bomb. Let's do it before the big corporations do it. Let's make it so it has rules to live by, ala Asimov's Laws of Robotics, that will break the programs before they can do any damage. It can be done. Nothing is beyond the reach of man when necessity comes knocking. Richard Anthony Hein -----Original Message----- From: me@m... [mailto:me@m...]On Behalf Of Jonathan Burns Sent: June 17, 2000 6:42 AM To: xpl@e... Subject: [XPL] [xpl-fog] To the Back Burner Richard, Kurt.... I'm gratified that you're seeing the same potential, and the same already-evident Big Picture that XPL is part of. I especially like Kurt's "systems programming on a global scale", and Richard's "command, data and structure are one". That last is something we really want to keep in mind, for the XPL architecture task at hand. That being said, I'm going to shelve further discussion on the far- fetched issues just for now. Too much else to assimilate. I'd like to recommend the title tag [xpl-fog] for discussions of free-floating (really peer-to-peer) architectures, and the security and social implications thereof. Jonathan ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:08:57
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Richard, Kurt.... I'm gratified that you're seeing the same potential, and the same already-evident Big Picture that XPL is part of. I especially like Kurt's "systems programming on a global scale", and Richard's "command, data and structure are one". That last is something we really want to keep in mind, for the XPL architecture task at hand. That being said, I'm going to shelve further discussion on the far-fetched issues just for now. Too much else to assimilate. I'd like to recommend the title tag [xpl-fog] for discussions of free-floating (really peer-to-peer) architectures, and the security and social implications thereof. Jonathan --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:08:42
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
For security we can use encryption defined by XSLT-like
transformations to
voice or visual recognition that matches to verification
transformations
supplied by someone who has your transformation key, and can then
supply the
correct data to parameters and what not. A firewall, like a blood
brain
barrier, does the verification, and so do the individual cells
(computers),
gates (method calls), and other components. It could work.
Richard Anthony Hein
-----Original Message-----
From: Richard Anthony Hein [mailto:935551@i...]
Sent: June 16, 2000 6:44 PM
To: xpl@e...
Subject: RE: [XPL] - WorldOS - framework for distributed computing
-----Original Message-----
From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
Sent: June 16, 2000 8:07 AM
To: xpl@e...
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.
[Richard Anthony Hein] Jonathan, this whole concept is like
the
brain, and like genetics, and it seems likely it's the language we
need for
artificial intelligence, and a learning, intelligent web. The brain's
neurons hold data of what we have input into our brain. Structures of
proteins, various types unlock memories and mix together in octoganal
structures in our dreams, sorting through information, trying to link
things
together that make sense with other memories, like a super-
defragmentation
process for pure data.
[Richard Anthony Hein] When a neuron fires, whether it fires or
not is
an all-or-nothing process; either it reaches a threshold of electrical
charge and fires, or it says at rest. Only the frequency of the
firing
varies ... this is like a component that only responsed when called
by the
correct parameters supplied. In the neuron the parameters are the
neurotransmitters - keys which unlock protein gateways that are only
opened
by those keys (although occasionally they are opened by drugs, and so
on,
which would be like a virus that calls XPL to process data).
Depending on
the combination of gates opened, which is dependent on the keys used,
which
activate internal processes in the neuron (XPL program), the
electrical
charge in the neuron increases or decreases (processes in XPL take
input and
activate internal data - which can be information calls to another XPL
program - and decide what to return, that activates calls to other
internal
or external data sources and XPL programs, and finally the return
value
comes back - send information or not ...), and finally the neuron
fires.
It could also apply to Jonathans cpu activation under the
spotlight
concept - when the right combination of XML is looked at by XPL
programs
that fits the XPL's filter it 'fires' the XPL which sends a signal to
another cpu that searches through other XPL program filters ...
millions via
the neural network peer-to-peer WorldOS - parameters of any self-
describing
media type using Groves of XML, down to each tree and branch and leaf
and
outputs a ... 'fruit' ... the combination of the media remaining and
presents it to the user. This process did all the formating using
XSLT and
other transformations, perhaps using XUL - we shouldn't overlook it,
but
until it becomes a standard we shouldn't ... perhaps XPL will have to
do it.
Also, XLink needs to work as Thomas Poe wrote in another follow
up.
Each client - which is a cpu needs to be able to create multi-
directional
links throughout it's data gas (maybe Jonathan, it could be likened
unto
"utility fog" taken from nanotechnology science fiction, and be
called "data
fog". Now we need to build the structure and movement - the XPL -
and like
the neuron, the data, commands, and structure are one. Each command
is
data, and data is a structure and a structure is a program. The cpu
operates on them using parameterized calls with data that is a
structure and
a command - which was put together by other cpus, calls and
operations. If
I have repeated myself, it's because I want everyone to see it.
When holographic techniques, like the research on tiny cubes
the size
of a grain of sugar that can store 10,000 web pages, that are
accessed by
different angles of light (gates) instantly sending a sigal in a yet
to be
optical computer will allow any kind of media ... to be accessed and
sorted
by matching the optical pattern (the letter's shapes themselves
BECOME the
keys to the gates - the commands, the structure, and the data! Does
anyone
see the deepness this goes to?? Think about vision, thought! If you
take
XML to describe the physical world, XSLT goes over it ... the outward
appearance is different, but it's the same thing ... like apples come
in
different shapes, syles, and kinds, but they are all apples, but what
it is
the same because it has the same underlying being ... the XML! Think
hearing! Sound described as XML matches media of sound translated by
XPL
processes calling XSLT to output as sound, or display as sheet music,
or
combine scales, modes, frequencies and make music! When a person
speaks to
a computer, their is a transformation made into XML data - each
person has
their own 'HXSLT' language to transform it!
Wow! Someday when we have nanotechnology that simply senses
structure
variations we can take those and describe them too in XML. The robot
will
sense structural changes and respond using tiny cpus and match them to
learned patterns stored in it's data store within it's neural net.
This is
artificial intelligence! Taste and smell would follow.
This is beyond the scope of XPL. I think we should talk to
artificial
intelligence and neural network scientists, and maybe DARPA. In the
meantime, XPL still has to be designed based on what we have come to,
if the
vision will become real.
Do we want it to happen? Should it happen?
Richard Anthony Hein
----------------------------------------------------------------------
----
----------------------------------------------------------------------
----
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 ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:08:05
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
-----Original Message-----
From: me@m... [mailto:me@m...]On
Behalf Of Jonathan Burns
Sent: June 16, 2000 8:07 AM
To: xpl@e...
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.
[Richard Anthony Hein] Jonathan, this whole concept is like the
brain,
and like genetics, and it seems likely it's the language we need for
artificial intelligence, and a learning, intelligent web. The brain's
neurons hold data of what we have input into our brain. Structures of
proteins, various types unlock memories and mix together in octoganal
structures in our dreams, sorting through information, trying to link
things
together that make sense with other memories, like a super-
defragmentation
process for pure data.
[Richard Anthony Hein] When a neuron fires, whether it fires or
not is
an all-or-nothing process; either it reaches a threshold of electrical
charge and fires, or it says at rest. Only the frequency of the
firing
varies ... this is like a component that only responsed when called
by the
correct parameters supplied. In the neuron the parameters are the
neurotransmitters - keys which unlock protein gateways that are only
opened
by those keys (although occasionally they are opened by drugs, and so
on,
which would be like a virus that calls XPL to process data).
Depending on
the combination of gates opened, which is dependent on the keys used,
which
activate internal processes in the neuron (XPL program), the
electrical
charge in the neuron increases or decreases (processes in XPL take
input and
activate internal data - which can be information calls to another XPL
program - and decide what to return, that activates calls to other
internal
or external data sources and XPL programs, and finally the return
value
comes back - send information or not ...), and finally the neuron
fires.
It could also apply to Jonathans cpu activation under the
spotlight
concept - when the right combination of XML is looked at by XPL
programs
that fits the XPL's filter it 'fires' the XPL which sends a signal to
another cpu that searches through other XPL program filters ...
millions via
the neural network peer-to-peer WorldOS - parameters of any self-
describing
media type using Groves of XML, down to each tree and branch and leaf
and
outputs a ... 'fruit' ... the combination of the media remaining and
presents it to the user. This process did all the formating using
XSLT and
other transformations, perhaps using XUL - we shouldn't overlook it,
but
until it becomes a standard we shouldn't ... perhaps XPL will have to
do it.
Also, XLink needs to work as Thomas Poe wrote in another follow
up.
Each client - which is a cpu needs to be able to create multi-
directional
links throughout it's data gas (maybe Jonathan, it could be likened
unto
"utility fog" taken from nanotechnology science fiction, and be
called "data
fog". Now we need to build the structure and movement - the XPL -
and like
the neuron, the data, commands, and structure are one. Each command
is
data, and data is a structure and a structure is a program. The cpu
operates on them using parameterized calls with data that is a
structure and
a command - which was put together by other cpus, calls and
operations. If
I have repeated myself, it's because I want everyone to see it.
When holographic techniques, like the research on tiny cubes the
size of
a grain of sugar that can store 10,000 web pages, that are accessed by
different angles of light (gates) instantly sending a sigal in a yet
to be
optical computer will allow any kind of media ... to be accessed and
sorted
by matching the optical pattern (the letter's shapes themselves
BECOME the
keys to the gates - the commands, the structure, and the data! Does
anyone
see the deepness this goes to?? Think about vision, thought! If you
take
XML to describe the physical world, XSLT goes over it ... the outward
appearance is different, but it's the same thing ... like apples come
in
different shapes, syles, and kinds, but they are all apples, but what
it is
the same because it has the same underlying being ... the XML! Think
hearing! Sound described as XML matches media of sound translated by
XPL
processes calling XSLT to output as sound, or display as sheet music,
or
combine scales, modes, frequencies and make music! When a person
speaks to
a computer, their is a transformation made into XML data - each
person has
their own 'HXSLT' language to transform it!
Wow! Someday when we have nanotechnology that simply senses
structure
variations we can take those and describe them too in XML. The robot
will
sense structural changes and respond using tiny cpus and match them to
learned patterns stored in it's data store within it's neural net.
This is
artificial intelligence! Taste and smell would follow.
This is beyond the scope of XPL. I think we should talk to
artificial
intelligence and neural network scientists, and maybe DARPA. In the
meantime, XPL still has to be designed based on what we have come to,
if the
vision will become real.
Do we want it to happen? Should it happen?
Richard Anthony Hein
----------------------------------------------------------------------
------
----------------------------------------------------------------------
------
--
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:07:22
|
--- 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. Comments, please?! Michael http://www.geocities.com/SiliconValley/Way/9180/ 'Eat, drink, and be merry, for tomorrow you may work.' --- End forwarded message --- |
1 message has been excluded from this view by a project administrator.
