[exprla-devel] Re: Requirements for Discussion

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

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

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

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

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

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

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

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

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

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

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

> 
>   1.12 Generation of XPL elements by external events.

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

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

Definetely.

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

A+

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

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

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

Absolutely!

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

Good.

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

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

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

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


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