Thread: [exprla-devel] RE: [XPL] project suggestion
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:20
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Mark is right. We need a mandate. Goal and purpose. I am looking at XPL as being a chance to reinvent the way people program. I see it as a chance to explore avenues not yet explored. Sorry if that isn't what everyone else wants to do. I will work within the overall vision of the project, but that won't stop me from spitting out ideas that might seem like overboard to others, or in the completely wrong direction. But we don't really have a direction I can determine. We really need a requirements draft, then we can all add and update parts we feel need changing. How about we all submit up to 10 requirements each. Then we'll all take time to consider the requirements, and change the requirements wording if necessary. Then we can remove things - the ones that are too much or in a wrong direction, and then go through another round of requirements submissions, including things that the requirements themselves require. Then we can debate the final list. Vote. Maybe have another round, if enough people think we should. Submit a working draft - or whatever comes first, I can't remember - to the W3C. Then we will have our mandate. Then we look at syntax and things like that. Maybe this could come before the working draft, I don't know ... I don't think it should though. Because someone who has a real talent for this could come along after we submit recommendations with a great way to do it. Not to say no one here can do it, the current tag set looks fine, but it's just the beginning of something that should be done really well so as many people as possible can understand it, but it's still simple. I suppose we could use recommended syntaxes from people before the submission: One or two syntax recommendations from people?? Then we can mix and match the best of them? That could work. Then we start the real heavy work (this doesn't mean you aren't thinking during the earlier process :-) ) of constructing a language, meant to be able to control any variety of devices and users and security concerns ... yeesh. I'm doing this for what?? :-) Why climb a mountain, eh? :-D Anyhow, I recommend that XPL be a full language. Not just business transactions. XPL is TOO extensible to not allow it to fit all programming uses. Compiled code is machine language binary ... it doesn't matter what language it's written in, therefore XPL could be a base language for all uses, as you should be able to streamline your XPL as a programmer to meet the unique needs of your program. If you are doing simulations you should be able to write in XPL by using different classes - even ones that are written in other languages, like C++ (of course we can use SOAP to allow us to use this code with XPL - this should be a requirement - but not limited only to SOAP, anyone should be able to extend XPL to utilize other means). I would bet the farm, that the most common use of XPL in the earliest period of growth in this world will be to access pre-built components, like COM++ and Java Beans, and your C++ class wrapped in SOAP, and some guy's VB module in Timbuktu. So, I think XPL should be written in such a way that getting access to these objects should be part of the language so that XPL handles heterogenous components in a way that is easy as pie, tying them together better than anything currently available. Make a program "serve itself" - accesses the components but really does no processing itself of the logic ... the program you write is really just instructions on which components to run and where to send the data next in this type of situation. And so XPL should be able to do that really well. Of course we can write logic as well! I also can't shake the idea of being able to "see" XPL anyway we want to. I think the IDE is something integrally part of the programming language. It is because today we see people using all kinds of languages together, and only VS7, which is still vaporware, promises to tie these things together. The VS7 will be a heterogenous one. I think XPL should allow IDE building to be something uniquely available to the user. I know that we can use XSLT to do this and it's not fundamental to the actual language. That's the way it should be. But, we must build XPL on top of, and around the XSLT specs. XSLT can allow us to use XPL as a symbolic language, verbose language, simple language, C++ like or even C++, etc... That's what I mean by the IDE is the language. People could use a XSLT rendered version of XPL that is itself an interactive IDE. Placing the cube within a bigger cube should result in XPL code that describes it. People from any walk of life should be able to use "rendered" XPL in a way that is simple for them to understand. This is beyond UML that is tied to the code, or if you have been keeping up with MS stuff, Biztalk Orchestrator, which ties visual objects to code so business guys can work alongside coders easily, and it is all the same underneath ... they are just representations of the same data (the data being the language of it all). XPL can and should do this and more in conjunction with XSLT. If you think that the IDE isn't the language, why is it easier to write using the editor of your choice, then pure text code? Because people speak that language more easily. A person who programs in VB sometimes barely has to look at the code. They use the RAD language subset of VB. The IDE, especially WYSIWYG editors allow you to speak the language in a way that is easier for you to understand. XPL should recognize this, and exploit it. This is all work for XSLT to do, but nevertheless, we can make it easier for XSLT to do using XPL! Hence, XPL should be developed in parallel (in as much as it is possible) with a few standard sets of XSL transformations that build an IDE for XPL. This will teach us what we can do to make it easier and better. So, for example, I am willing, after we go through the requirement stage, to try to XSL transform some XPL function that performs a simple mathematical function into MathML and back again into XPL. Something harder, like XSL transforming code that draws a box on screen, then allowing manipulation of the box size, and transform back to XPL sounds harder to me, but we should be able to do it. Then make it an input box ... things like that. These would, and could be all stages in development to see if it really can work the way I am descibing here. Sorry if you read all of this ...! Right now, the requirements are enough to think about. I'll make up my list. Richard A. Hein -----Original Message----- From: Mark Wilson [mailto:mark_tracey@y...] Sent: June 10, 2000 8:02 AM To: xpl@e... Subject: [XPL] project suggestion Is anyone in here interested in outlining this project's goals, progress, W3C status(?), integration to other projects and if/how people can become involved etc. and forwarding it to me in email, so I can list it as an article on http://www.vbxml.com We get 40 000 unique visitors a month and they would be interested in something like this. Regardless of if you want to set up a home website on VBXML.COM, I would like to list a detailed description (including XML) as an article on VBXML.COM Please email responses directly to me. Cheers, Mark Wilson VBXML.COM Admin ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:57:39
|
--- In xpl-dev@y..., cagle@o... wrote:
Richard,
The requirements document sounds like a solid idea. Let me fill you
in on what I'm doing with VBXML -- Mark and I have talked about
creating a new site called XSLTalk, where we could set up a forum for
handling requirements. I worked on a critical part of the XPipes
framework today, and may even be in a position in the next couple of
days to set up message boards where we could solicit requirements.
That way rather than trying to sort things out in an arbitration
process we can set up discussions in something approaching real time.
My personal druthers is to take the problem from the other direction -
- define an architecture for integrating components on a generalized
basis, then add to the component base over time. Keep the language
itself relatively self contained, then move device functionality into
components. Reduce everything down to the movement of streams that
are largely transparent to device or file type. Abstract as much as
possible -- parameters may come from SOAP or query strings or forms
or anywhere else, follow emergent patterns rather than provide
specificity of code (not all treeviews are created equal, even though
the form is common to all). Remember that XML is first and foremost a
web language, and will not (and should not) replace more complex
compiled forms yet. Move the language slowly in that direction, of
course, get people to start thinking about XML as a language for
handling compiled forms but focus on XMLs strengths before extending
the language to better handle its weaknesses.
As I mentioned previously, I think an XML IDE is a cool idea, and
should be considered as a mechanism that could even be built using
XPL, but I would caution against concentrating on IDE too soon. In my
mind the purpose of XPL is to create an easy to use language that
doesn't require a lot of programming acument, that can be done using
the native forms of XML without a lot of exceptions, and that could
be written in a text editor if need be. It should be a language that
allows for the intermingling of XML (or XSLT or XPL), and that can be
extended transparently. The ability to communicate with devices, or
handle MathML streams, or to toggle between HTML and WML output
should be considered as very much secondary to building a cohesive
infrastructure for working with components in the first place.
I'll put together my requirements list on this and will see about
getting the XSLTalk website set up if that is what people are
comfortable with.
-- Kurt
----- Original Message -----
From: Richard Anthony Hein
To: xpl@e...
Sent: Saturday, June 10, 2000 11:05 AM
Subject: RE: [XPL] project suggestion
Mark is right. We need a mandate. Goal and purpose. I am looking
at XPL as being a chance to reinvent the way people program. I see
it as a chance to explore avenues not yet explored. Sorry if that
isn't what everyone else wants to do. I will work within the overall
vision of the project, but that won't stop me from spitting out ideas
that might seem like overboard to others, or in the completely wrong
direction. But we don't really have a direction I can determine.
We really need a requirements draft, then we can all add and update
parts we feel need changing. How about we all submit up to 10
requirements each. Then we'll all take time to consider the
requirements, and change the requirements wording if necessary. Then
we can remove things - the ones that are too much or in a wrong
direction, and then go through another round of requirements
submissions, including things that the requirements themselves
require. Then we can debate the final list. Vote. Maybe have
another round, if enough people think we should. Submit a working
draft - or whatever comes first, I can't remember - to the W3C.
Then we will have our mandate.
Then we look at syntax and things like that. Maybe this could come
before the working draft, I don't know ... I don't think it should
though. Because someone who has a real talent for this could come
along after we submit recommendations with a great way to do it. Not
to say no one here can do it, the current tag set looks fine, but
it's just the beginning of something that should be done really well
so as many people as possible can understand it, but it's still
simple. I suppose we could use recommended syntaxes from people
before the submission: One or two syntax recommendations from
people?? Then we can mix and match the best of them? That could
work.
Then we start the real heavy work (this doesn't mean you aren't
thinking during the earlier process :-) ) of constructing a language,
meant to be able to control any variety of devices and users and
security concerns ... yeesh. I'm doing this for what?? :-) Why
climb a mountain, eh? :-D
Anyhow, I recommend that XPL be a full language. Not just business
transactions. XPL is TOO extensible to not allow it to fit all
programming uses. Compiled code is machine language binary ... it
doesn't matter what language it's written in, therefore XPL could be
a base language for all uses, as you should be able to streamline
your XPL as a programmer to meet the unique needs of your program.
If you are doing simulations you should be able to write in XPL by
using different classes - even ones that are written in other
languages, like C++ (of course we can use SOAP to allow us to use
this code with XPL - this should be a requirement - but not limited
only to SOAP, anyone should be able to extend XPL to utilize other
means).
I would bet the farm, that the most common use of XPL in the
earliest period of growth in this world will be to access pre-built
components, like COM++ and Java Beans, and your C++ class wrapped in
SOAP, and some guy's VB module in Timbuktu. So, I think XPL should
be written in such a way that getting access to these objects should
be part of the language so that XPL handles heterogenous components
in a way that is easy as pie, tying them together better than
anything currently available. Make a program "serve itself" -
accesses the components but really does no processing itself of the
logic ... the program you write is really just instructions on which
components to run and where to send the data next in this type of
situation. And so XPL should be able to do that really well. Of
course we can write logic as well!
I also can't shake the idea of being able to "see" XPL anyway we
want to. I think the IDE is something integrally part of the
programming language. It is because today we see people using all
kinds of languages together, and only VS7, which is still vaporware,
promises to tie these things together. The VS7 will be a
heterogenous one. I think XPL should allow IDE building to be
something uniquely available to the user. I know that we can use
XSLT to do this and it's not fundamental to the actual language.
That's the way it should be. But, we must build XPL on top of, and
around the XSLT specs. XSLT can allow us to use XPL as a symbolic
language, verbose language, simple language, C++ like or even C++,
etc... That's what I mean by the IDE is the language. People could
use a XSLT rendered version of XPL that is itself an interactive
IDE. Placing the cube within a bigger cube should result in XPL code
that describes it. People from any walk of life should be able to
use "rendered" XPL in a way that is simple for them to understand.
This is beyond UML that is tied to the code, or if you have been
keeping up with MS stuff, Biztalk Orchestrator, which ties visual
objects to code so business guys can work alongside coders easily,
and it is all the same underneath ... they are just representations
of the same data (the data being the language of it all). XPL can
and should do this and more in conjunction with XSLT.
If you think that the IDE isn't the language, why is it easier to
write using the editor of your choice, then pure text code? Because
people speak that language more easily. A person who programs in VB
sometimes barely has to look at the code. They use the RAD language
subset of VB. The IDE, especially WYSIWYG editors allow you to speak
the language in a way that is easier for you to understand. XPL
should recognize this, and exploit it.
This is all work for XSLT to do, but nevertheless, we can make it
easier for XSLT to do using XPL!
Hence, XPL should be developed in parallel (in as much as it is
possible) with a few standard sets of XSL transformations that build
an IDE for XPL. This will teach us what we can do to make it easier
and better.
So, for example, I am willing, after we go through the requirement
stage, to try to XSL transform some XPL function that performs a
simple mathematical function into MathML and back again into XPL.
Something harder, like XSL transforming code that draws a box on
screen, then allowing manipulation of the box size, and transform
back to XPL sounds harder to me, but we should be able to do it.
Then make it an input box ... things like that. These would, and
could be all stages in development to see if it really can work the
way I am descibing here.
Sorry if you read all of this ...!
Right now, the requirements are enough to think about. I'll make
up my list.
Richard A. Hein
-----Original Message-----
From: Mark Wilson [mailto:mark_tracey@y...]
Sent: June 10, 2000 8:02 AM
To: xpl@e...
Subject: [XPL] project suggestion
Is anyone in here interested in outlining this project's goals,
progress, W3C status(?), integration to other projects and if/how
people can become involved etc. and forwarding it to me in email,
so
I can list it as an article on
http://www.vbxml.com
We get 40 000 unique visitors a month and they would be
interested in
something like this. Regardless of if you want to set up a home
website on VBXML.COM, I would like to list a detailed description
(including XML) as an article on VBXML.COM
Please email responses directly to me.
Cheers,
Mark Wilson
VBXML.COM Admin
----------------------------------------------------------------------
------
----------------------------------------------------------------------
------
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 08:57:54
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote: Kurt, The message board sounds great. I understand what you are saying about building the architecture, and you are right. I expect the component base will grow quite quickly over time, once we have that architecture in place, and so I concure. I would like to hear more about XPipes ... what's it all about - and XSLTalk, for that matter? When you say, "reduce everything down to the movement of streams" what exactly do you mean? I am not sure if you mean, don't worry about performing operations on the streams? Also, I am not sure what you mean about emergent patterns ... am I right in thinking you mean to allow the abstract architecture to handle the patterns which components follow in providing parameters for input and output, location, etc ...? Could you clarify this a bit for me? Yes, XML is a web language ... but the web is going to be everything! Let's take it slow and take care of the basics that XML excel in, yes, I can see that, but let's also keep in mind the future, so that we can extend it. I think making an extensible programming language isn't exactly easy ... we have to think of scenarios that may be required in the future, and try to plan for those eventualities. You're right, we don't have to build it to handle all the things that are and may decide come along ... it only means we have to be careful, to allow us to extend it to handle the future demands of the web. So, I do agree, as long as we remember not to lock XPL in to today's internet. Let's build it for today, and leave room for tomorrow, which XPL should do if the name means anything. My talk about an IDE is not asking the group to build one now. It's asking everyone to consider the idea that the IDE can be integrated into the language itself and the total look and feel of the IDE should be linked to the language in a way that hasn't been done before. I can almost see it as if when someone goes to start a new project in XPL, the IDE itself will become the application - if it is something that can be visual. So you start with this bare IDE, and simply select components, and buttons and what not, drop them where you want, and so on. This sounds just like using Visual Basic or something so far. But if you take it a step further, then the application is also an IDE to someone else ... you see? Then the user can change just about anything about the application, excepting perhaps the code that runs the core logic. Things like button type, input type can be changed to the users liking, and what not. Just like Mozilla can be a browser and the editor for XML pages. Of course, the authors of the program, or administrators should also be able to limit that sort of thing if necessary. I know we won't start by building the IDE, but what considerations do we need to put into the language to make this easier to do later? Is it possible? Does it make sense? Do we need to put design considerations into the language to support this, or will it work anyways? Will XSLT do it all for us? These are questions running through my head. The bottom line for me, is it would be something wonderful to bring programming to the average Joe. Maybe not for programmers ... but still. I hope XPL can do that. So anyways, before I write anymore, don't worry, I don't mean let's build an IDE now (aside from me trying out an XSLT after we get the architecture and syntax done - come on, it'd be fun!). I just think it is something to think about during the design of the language. Others may disagree, and almost certainly know a lot more than I do about this, so I defer to the better judgement of my peers. An article at www.xml.com about the "Semantic Web" talks about this sort of thing though, and I was hoping we could get it to happen for XPL. Maybe the group could take a look at the article so they can see where I am coming from with this idea? I agree with your third paragraph completely, although it might not seem like it from the messages I have been sending. I am just excited about the possibilities! :-) We absolutely must have the infrastructure, or else nothing else I have been thinking about will ever work anyways! So, let's get the requirements together! I have a few already, but I will send that with the rest, when I get them sorted out. Thanks Kurt, for being patient (and the rest of XPLers)! I have never designed a language before, so bear with me and my far reaching (or fetched) ideas about what it should do! Richard A. Hein -----Original Message----- From: cagle@o... [mailto:cagle@o...] Sent: June 11, 2000 12:01 AM To: xpl@e... Subject: Re: [XPL] project suggestion Richard, The requirements document sounds like a solid idea. Let me fill you in on what I'm doing with VBXML -- Mark and I have talked about creating a new site called XSLTalk, where we could set up a forum for handling requirements. I worked on a critical part of the XPipes framework today, and may even be in a position in the next couple of days to set up message boards where we could solicit requirements. That way rather than trying to sort things out in an arbitration process we can set up discussions in something approaching real time. My personal druthers is to take the problem from the other direction -- define an architecture for integrating components on a generalized basis, then add to the component base over time. Keep the language itself relatively self contained, then move device functionality into components. Reduce everything down to the movement of streams that are largely transparent to device or file type. Abstract as much as possible -- parameters may come from SOAP or query strings or forms or anywhere else, follow emergent patterns rather than provide specificity of code (not all treeviews are created equal, even though the form is common to all). Remember that XML is first and foremost a web language, and will not (and should not) replace more complex compiled forms yet. Move the language slowly in that direction, of course, get people to start thinking about XML as a language for handling compiled forms but focus on XMLs strengths before extending the language to better handle its weaknesses. As I mentioned previously, I think an XML IDE is a cool idea, and should be considered as a mechanism that could even be built using XPL, but I would caution against concentrating on IDE too soon. In my mind the purpose of XPL is to create an easy to use language that doesn't require a lot of programming acument, that can be done using the native forms of XML without a lot of exceptions, and that could be written in a text editor if need be. It should be a language that allows for the intermingling of XML (or XSLT or XPL), and that can be extended transparently. The ability to communicate with devices, or handle MathML streams, or to toggle between HTML and WML output should be considered as very much secondary to building a cohesive infrastructure for working with components in the first place. I'll put together my requirements list on this and will see about getting the XSLTalk website set up if that is what people are comfortable with. -- Kurt --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:58:13
|
--- In xpl-dev@y..., "Tony Edgecombe" <tony.edgecombe@f...> wrote: I have to agree with your comments on an IDE, for the last couple of years I have been working with a product (www.formscape.com) which allows you to build applications in a simple tree based drag and drop environment. I can see a direct corellation between the structure of this tree and some of the schemas talked about early on in this group. In this particular case the software is focussed on formatted output but the principles could apply to any type of application. The big benifit this allows is the configuration of complex applications by non programmers (sometimes!) and very rapid development because of the high level of abstraction. It could be that this element of XPL is crucial to the adoption of the language. XML is not the easiest thing to read or write when littered with namespaces and attributes, anything but the simplist of programs could be very frustating to construct. Tony -----Original Message----- From: Richard Anthony Hein [mailto:935551@i...] Sent: 11 June 2000 07:34 To: xpl@e... Subject: RE: [XPL] project suggestion Kurt, The message board sounds great. I understand what you are saying about building the architecture, and you are right. I expect the component base will grow quite quickly over time, once we have that architecture in place, and so I concure. I would like to hear more about XPipes ... what's it all about - and XSLTalk, for that matter? When you say, "reduce everything down to the movement of streams" what exactly do you mean? I am not sure if you mean, don't worry about performing operations on the streams? Also, I am not sure what you mean about emergent patterns ... am I right in thinking you mean to allow the abstract architecture to handle the patterns which components follow in providing parameters for input and output, location, etc ...? Could you clarify this a bit for me? Yes, XML is a web language ... but the web is going to be everything! Let's take it slow and take care of the basics that XML excel in, yes, I can see that, but let's also keep in mind the future, so that we can extend it. I think making an extensible programming language isn't exactly easy ... we have to think of scenarios that may be required in the future, and try to plan for those eventualities. You're right, we don't have to build it to handle all the things that are and may decide come along ... it only means we have to be careful, to allow us to extend it to handle the future demands of the web. So, I do agree, as long as we remember not to lock XPL in to today's internet. Let's build it for today, and leave room for tomorrow, which XPL should do if the name means anything. My talk about an IDE is not asking the group to build one now. It's asking everyone to consider the idea that the IDE can be integrated into the language itself and the total look and feel of the IDE should be linked to the language in a way that hasn't been done before. I can almost see it as if when someone goes to start a new project in XPL, the IDE itself will become the application - if it is something that can be visual. So you start with this bare IDE, and simply select components, and buttons and what not, drop them where you want, and so on. This sounds just like using Visual Basic or something so far. But if you take it a step further, then the application is also an IDE to someone else ... you see? Then the user can change just about anything about the application, excepting perhaps the code that runs the core logic. Things like button type, input type can be changed to the users liking, and what not. Just like Mozilla can be a browser and the editor for XML pages. Of course, the authors of the program, or administrators should also be able to limit that sort of thing if necessary. I know we won't start by building the IDE, but what considerations do we need to put into the language to make this easier to do later? Is it possible? Does it make sense? Do we need to put design considerations into the language to support this, or will it work anyways? Will XSLT do it all for us? These are questions running through my head. The bottom line for me, is it would be something wonderful to bring programming to the average Joe. Maybe not for programmers ... but still. I hope XPL can do that. So anyways, before I write anymore, don't worry, I don't mean let's build an IDE now (aside from me trying out an XSLT after we get the architecture and syntax done - come on, it'd be fun!). I just think it is something to think about during the design of the language. Others may disagree, and almost certainly know a lot more than I do about this, so I defer to the better judgement of my peers. An article at www.xml.com about the "Semantic Web" talks about this sort of thing though, and I was hoping we could get it to happen for XPL. Maybe the group could take a look at the article so they can see where I am coming from with this idea? I agree with your third paragraph completely, although it might not seem like it from the messages I have been sending. I am just excited about the possibilities! :-) We absolutely must have the infrastructure, or else nothing else I have been thinking about will ever work anyways! So, let's get the requirements together! I have a few already, but I will send that with the rest, when I get them sorted out. Thanks Kurt, for being patient (and the rest of XPLers)! I have never designed a language before, so bear with me and my far reaching (or fetched) ideas about what it should do! Richard A. Hein -----Original Message----- From: cagle@o... [mailto:cagle@o...] Sent: June 11, 2000 12:01 AM To: xpl@e... Subject: Re: [XPL] project suggestion Richard, The requirements document sounds like a solid idea. Let me fill you in on what I'm doing with VBXML -- Mark and I have talked about creating a new site called XSLTalk, where we could set up a forum for handling requirements. I worked on a critical part of the XPipes framework today, and may even be in a position in the next couple of days to set up message boards where we could solicit requirements. That way rather than trying to sort things out in an arbitration process we can set up discussions in something approaching real time. My personal druthers is to take the problem from the other direction -- define an architecture for integrating components on a generalized basis, then add to the component base over time. Keep the language itself relatively self contained, then move device functionality into components. Reduce everything down to the movement of streams that are largely transparent to device or file type. Abstract as much as possible -- parameters may come from SOAP or query strings or forms or anywhere else, follow emergent patterns rather than provide specificity of code (not all treeviews are created equal, even though the form is common to all). Remember that XML is first and foremost a web language, and will not (and should not) replace more complex compiled forms yet. Move the language slowly in that direction, of course, get people to start thinking about XML as a language for handling compiled forms but focus on XMLs strengths before extending the language to better handle its weaknesses. As I mentioned previously, I think an XML IDE is a cool idea, and should be considered as a mechanism that could even be built using XPL, but I would caution against concentrating on IDE too soon. In my mind the purpose of XPL is to create an easy to use language that doesn't require a lot of programming acument, that can be done using the native forms of XML without a lot of exceptions, and that could be written in a text editor if need be. It should be a language that allows for the intermingling of XML (or XSLT or XPL), and that can be extended transparently. The ability to communicate with devices, or handle MathML streams, or to toggle between HTML and WML output should be considered as very much secondary to building a cohesive infrastructure for working with components in the first place. I'll put together my requirements list on this and will see about getting the XSLTalk website set up if that is what people are comfortable with. -- Kurt ---------------------------------------------------------------------- ------ -- ---------------------------------------------------------------------- ------ -- To unsubscribe from this group, send an email to: xpl-unsubscribe@o... --- 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