Thread: [exprla-devel] Re: [XPL] Re: a domain name for XPL
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:36:45
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote: Mark Wilson wrote: > > OR! > > you guys could simply move into the > http://www.vbxml.com/xpl > location I set up for you some time back. > > That would bring 40 000 visitors each month into > contact with this project - quite a boost! Then when > you have a URL, then move in there (if you still think > you would be better off). > > Thoughts? > > Cheers, > Mark You know, fellows, he's perfectly right. [ Cue piano ] [ ROFL ] Okay, okay! Enough with the piano. Ahem... Any attention or respect the list gets, will be on account of our own efforts. Not that I mind, in the least, the extended umbrella of VBXML, which would seem to include us in as sound and pleasant a company as we could ask for. And anyway, don't we all rather have our toes sticking out the ends of our feet? What we need, is a stable location in a nice and also relevant neighbourhood, where we can put our findings, if any, where people can actually find them, and meanwhile inviting passers-by to join in the rowdy-do. Plus, an isolated brick shed where we can let off explosions. Is there any reason why I can't just say on behalf of all of us, THANK YOU TRACE for the former, and THANK YOU LUCAS for the other? If not, be it so resolved; and when I am once again in funds, I will gladly pay for hamburgers all round, instead. Jonathan Burns; saski@w... Thus, my dull official .signature. Thought that went off just as well without the piano, don'tcha think? Yeah. Y'know what we need is a religious war or two going on. Bring the punters in, liven the place up. --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:37:05
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Ok, suits me just fine.
[Richard Anthony Hein] From: me@m...
[mailto:me@m...]On Behalf Of Jonathan Burns
Sent: July 4, 2000 10:39 AM
To: xpl@e...
Subject: Re: [XPL] Re: a domain name for XPL
Mark Wilson wrote:
OR!
you guys could simply move into the
http://www.vbxml.com/xpl
location I set up for you some time back.
That would bring 40 000 visitors each month into
contact with this project - quite a boost! Then when
you have a URL, then move in there (if you still think
you would be better off).
Thoughts?
Cheers,
Mark
You know, fellows, he's perfectly right.
[ Cue piano ]
[ ROFL ]
Okay, okay! Enough with the piano. Ahem...
Any attention or respect the list gets, will be on account of our
own efforts.
Not that I mind, in the least, the extended umbrella of VBXML,
which would seem to include us in as sound and pleasant a
company as we could ask for.
And anyway, don't we all rather have our toes sticking out the
ends of our feet?
What we need, is a stable location in a nice and also relevant
neighbourhood, where we can put our findings, if any, where people
can actually find them, and meanwhile inviting passers-by to join
in the rowdy-do.
Plus, an isolated brick shed where we can let off explosions.
Is there any reason why I can't just say on behalf of all of us,
THANK YOU TRACE for the former, and THANK YOU LUCAS for the other?
If not, be it so resolved; and when I am once again in funds,
I will gladly pay for hamburgers all round, instead.
Jonathan Burns; saski@w...
Thus, my dull official .signature.
Thought that went off just as well without the piano, don'tcha
think?
Yeah. Y'know what we need is a religious war or two going on. Bring
the punters in, liven the place up.
----------------------------------------------------------------------
------
--
----------------------------------------------------------------------
------
--
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:37:35
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Kurt, One of the names I sent you might be good for your XPipes project; if you like it, go ahead and take it - not like I could stop you, but you have my blessing in any case. Michael is talking about http://www.vbxml.com/xpl There hasn't been anything posted there since the beginning though. I am worried about the health of XPL now; we haven't been getting the requirements or anything done. I have been working on compiling up the stuff we've discussed to put it in a format that's easier for new people to get a grip on the things we've been talking about, and for people who have been following the conversations to review and comment on past discussions that have never been resolved. Unfortunately, I have just gotten carpal tunnel syndrome, and my right wrist is killing me. So it's going to take a while before I get it done. Maybe a week. At that time, hopefully we will have a web site layout and can post some articles on XPL's status, including "The State of XPL", as I am calling my compilation and review article. Kurt, I remember going over an article on vbxml about making an XML/XSL content management document, allowing examples and articles to be easily updated with new code samples and tutorial articles. I think this would be a good layout for my document, especially if people can annotate in the article and code sections. The straight article is simple enough. Any ides about how to expand the concept to make it annotatable? Or does anyone have any better ideas on some decent ways to collaborate on documents at the site? Software suggestions, high-level concepts and raw code are all requested on this issue. We also need a way to accept registration for the XPL site. In addition, someone with knowledge about licensing will have to find out what the legal issues are, if we post information about XPL. I am not sure, but I think if we just give away information without copyrighting it in some fashion, people can just steal it and use it on their own proprietary projects. Then in the future, XPL could be harmed if that person/company tries to sue us for using "their" code. Any thoughts? I think there are so many issues that touch on XPL right now that are not being discussed. The new language C# that Microsoft is developing might not be the same syntactically to XPL's ideas, but it is built on the concept of XML "data clouds" (that's MS's term for XML-fog), and web services. This is a direct competitor to XPL. I was reviewing the W3C's information on how to start an activity group, what documentation is needed, and what should be in that documentation (a "Note"), and one of the issues is what competition is out there. There are other issues that demand attention, and so I have been trying to expose people to those questions. How does XPL compare to other technologies, is one of them. What effect will XPL have on other technologies (specifically W3C's, but also others), what dependencies exist, and so forth. These all MUST be discussed and put into the Note, for it to even be considered. Of course there isn't much point in trying to discuss this, if we haven't even answered the question: What is XPL supposed to accomplish? When I asked for requirements, that's what I meant. I still think other general requirements are good to have right now, but the most vital are concerning what XPL is supposed to DO. Is it a full-out language? A meta-language? An engine to stream and coordinate other XML technologies? Does it work with the "fog", as a "fog"? Etc .... Remember when I wrote, "don't put the genie back into the bottle", Jonathan et al? Take a look at what Microsoft's .NET concept is dedicated to accomplishing, and tell me - isn't that the genie? MS is already working big time on "data clouds" of XML and web services that use them. Oracle thinks they already have it with .NOW (rediculous), and Sun claims it will be done with Java using J2EE. There is no opensource equivalent to compete against these corporations right now, that I can see. Plus, they are all trying to do it with technology that was never meant to pull off this feat. It's really just a great big HACK. So, if we start with a blank state, based on TOTALLY standard implementation across the board, I think it won't take "many, many years" to pull off the way MS says it will, as they try to figure out hacks to everything. But it will still take "many years" to pull off, and a LOT of people. The Apache group, Mozilla, etc, are all sources from which to draw strength. So let's build up the vision of what XPL will BE, and recruit people to help make it happen. Here's a format: 1.. XPL will stream XML data, in an asynchronous and/or synchronous format, and support multiple streams of heterogeneous data, including non-XML media types. 2.. XPL will format output using XSL. 3.. XPL will transform XML data using XSLT. 4.. XPL will be optimized to operate on a peer-to-peer network, however client-server models and offline computing will also be supported fully. 5.. XPL will use agents, among other methods to operate on XML. 6.. XPL will use RDF to locate resources. 7.. XPL will use XLink to create, follow, and generate links between resources. 8.. XPL will use XPath as the language to describe resource locations. 9.. XPL will be an interface-based object-oriented language, and the interfaces will be exposed as XML 1.0 compliant XML (although the programs themselves may or may not be). 10.. XPL will NEVER support APIs that are not FULLY opensource and public domain, as closed source APIs may fork XPL. Anyone MAY create private APIs, however, they MAY NOT publish or redistribute said APIs outside of private or corporate usage, unless first reviewed, accepted, integrated (into the XPL API library) and simultaneously published by the XPL working group. Upon such an event, the API also becomes opensource and public domain under the license terms which XPL operates under (yet to be decided). There's ten. They are simple, and say at least a few things that XPL will do. Comments? Number 10 is a tricky one. Richard A. Hein -----Original Message----- From: cagle@o... [mailto:cagle@o...] Sent: July 4, 2000 11:24 AM To: xpl@e... Subject: Re: [XPL] Re: a domain name for XPL Oh, I missed that one. When did you set it up? -- Kurt ----- Original Message ----- From: "Mark Wilson" <mark_tracey@y...> To: <xpl@e...> Sent: Tuesday, July 04, 2000 5:17 AM Subject: [XPL] Re: a domain name for XPL > > OR! > > you guys could simply move into the > http://www.vbxml.com/xpl > location I set up for you some time back. > > That would bring 40 000 visitors each month into > contact with this project - quite a boost! Then when > you have a URL, then move in there (if you still think > you would be better off). > > Thoughts? > > Cheers, > Mark. > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > > ------------------------------------------------------------------ ------ > Replace complicated scripts using 14 new HTML tags that work in > current browsers. > Form the Web today - visit: > http://click.egroups.com/1/5769/2/_/809694/_/962713022/ > ------------------------------------------------------------------ ------ > > 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:40:03
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Richard Anthony Hein wrote:
>
>
> 1. XPL will stream XML data, in an asynchronous and/or synchronous
> format, and support multiple streams of heterogeneous data,
> including non-XML media types.
>
I support this as a requirement, except that I'm not sure what
"synchronous" and "asynchronous"
mean in context here.
From my simple hardware background, "synchronous" means: multiple
processes are going on;
their outputs must be combined, and delivered in a correct order; to
ensure this, processes are
constrained to open for input or output only on logical conditions,
which are dependent on a
global counter or timestamping system.
Is this the sense of things for Web protocols? Lucas? Kurt?
> 1. XPL will format output using XSL.
>
I don't know about this. Is XSL diverse enough to drive the range of
output mechanisms
in current use? Can it efficiently make method calls to COM objects?
Talk to Java Beans?
Generate Perl, or Postscript?
I mean, it was beginning to sound to me that SOAP would make the right
kind of output
stage for most purposes.
> 1. XPL will transform XML data using XSLT.
>
No.
I want a weaker requirement than that. Say,
"All XSLT transformations will be valid XPL operations."
From what I've seen so far, and I emphasize that I've seen a lot more
trees than forests,
I can accept Groves as The inclusive foundation for XPL - but XSLT
only
as a standard
XPL subset, possibly one among many.
Because my impression is, that the XSLT people spend a lot of time
working out how
to make it serve fairly simple ends. It's not just that the XML syntax
is unwieldly,
it's that they can't work out how the pieces fit together.
What I want, and I'll canvas it as a requirement, is:
"XPL operations will be derived from a simple and comprehensible set
of
basic principles."
What might the basics be? I'm not completely sure, but here are the
ones
I'd bet on, currently:
* Recursion.
* Uniform definition of node structure - i.e. architectural forms.
* Recursion in node connectivity definitions - i..e. groves &
hypergroves.
* Regular expressions (regexps) , for text parsing.
* Regular languages (grammars), for document type definition.
* Document types as first-class objects.
* Execution by means of pattern (i.e. regexp) recognition and
substitution.
* Easy use of divide-and-conquer algorithms.
* Object-oriented programming.
Each of these has either, an inherent simplicity, or a coherent
theoretical basis.
Except maybe for OOP, but OOP includes important principles of
distinction
such as encapsulation, which help avoid inappropriate couplings.
Obviously, I'll need to explain some of these principles really soon.
I
was hoping for
more time, to do a compare-and-contrast between XSLT and several other
widespread
tree-structured programming-language paradigms, before I opened my
yap.
Going into
them right now means setting aside the first JDK I've ever used,
before
I've had any
hands-on with XML at all.
I'll back up and do it if need be - but I think it's premature. I
really
have to mobilize
the XML/XSL machinery, and run a few stylesheets of a few documents,
before I
can seriously judge the worth of XSLT.
> 1. XPL will be optimized to operate on a peer-to-peer network,
> however client-server models and offline computing will also be
> supported fully.
>
Lucas Gonze is the one to ask about this.
Lucas, what features in an XML-processing system (think of this as
pipelining
XLST transformations) would make it most suitable for efficient use
of a
peer-to-peer protocol such as WorldOS?
> 1. XPL will use agents, among other methods to operate on XML.
>
I agree - at least so far as I understand agents. We're talking about
XPL documents,
i.e. programs, which wander about in the fog, processing public
documents and
dispatching the results to their owners or to public collections - am
I
right?
> 1. XPL will use RDF to locate resources.
>
This sounds right. RDF is a siteless, content-addrssed structure, if I
recall.
But, and I hate to say this, RDF is one more semi-standard for me to
study up -
and compare with Linda, which sounds similar - before I can pronounce.
> 1. XPL will use XLink to create, follow, and generate links
between
> resources.
>
> 1. XPL will use XPath as the language to describe resource
> locations.
>
Same qualms as with XSLT.
> 1. XPL will be an interface-based object-oriented language, and
the
> interfaces will be exposed as XML 1.0 compliant XML (although
the
> programs themselves may or may not be).
>
I'm sure this is right.
> 1. XPL will NEVER support APIs that are not FULLY opensource and
> public domain, as closed source APIs may fork XPL.
>
Rather than "never support", I would like to require "never be
dependent
on".
If XPL turns out to be really useful, private outfits will define
support in it for their
own APIs, and the specification will fork.
> 1. Anyone MAY create private APIs, however, they MAY NOT publish
or
> redistribute said APIs outside of private or corporate usage,
> unless first reviewed, accepted, integrated (into the XPL API
> library) and simultaneously published by the XPL working group.
> Upon such an event, the API also becomes opensource and public
> domain under the license terms which XPL operates under (yet to
> be decided).
>
I don't see that we have the right to require this of anyone, or the
ability to enforce it.
As an analogy, does W3C have any right to prevent, say Allaire from
reproducing
XSLT as a feature of Cold Fusion?
I certainly understand the intention to reject any engulf-and-extend
monkey business
on the part of private corps. I'm just not sure that we can.
> There's ten. They are simple, and say at least a few things that
XPL
> will do. Comments? Number 10 is a tricky one. Richard A. Hein
Sorry if I seem balky on some of these. They are the right questions
to
ask,
it's just that I plain don't know some of the answers.
Back soon
Jonathan
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-02-01 03:38:46
|
--- In xpl-dev@y..., Lucas Gonze <lucas@g...> wrote: > > 1. XPL will stream XML data, in an asynchronous and/or > > synchronous format, and support multiple streams of > > heterogeneous data, including non-XML media types. ... > From my simple hardware background, "synchronous" means: > multiple processes are going on; > their outputs must be combined, and delivered in a correct > order; to ensure this, processes are > constrained to open for input or output only on logical > conditions, which are dependent on a > global counter or timestamping system. Async in this context means that messages can arrive at any time from any party. This is in contrast to http, where messages come in request/response pairs and must be initiated by one party (a browser/client) and never the other (a http daemon). I would leave streaming to the transport stage - ignore the issue unless there is a specific reason why you can't. All it requires is some type of chunked encoding. the only language design issue I can think of is that asynchronous function calls mean function calls that can have 0 or n responses, instead of 1 and always 1 response. this is a feature I have never seen in a language. --- End forwarded message --- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X