[exprla-devel] [XPL] requirements

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

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

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

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

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

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

3.  XPL must be human readable.

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

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

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

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

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

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

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

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


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