--- 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 ---
|
