Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Feasibility of "do all application coding in the XML

From: Jonas Mellin <jonas.mellin@---.-->
To: Mukul Gandhi <gandhi.mukul@-----.--->
Date: 12/3/2008 9:30:00 AM
Mukul Gandhi wrote:
> Hi Roger,
>    There are many software applications, which need imperative
> programming infrastructure (where we should be able to change program
> state at will, like using assignment statement as so on).
>
> Examples of such applications could be,
> 1. Complex business logic (say I am implementing a work flow for an
> insurance company)
> 2. Game programming :)
> 3. GUI programming
>   
I do not think anyone mentioned the obvious infeasibility of systems 
with limited resources in terms of processor capacity, memory, I/O 
availability as well as working in potentially hostile environments 
(e.g., no cooling possible, satellites). I partly work with wireless 
sensor networks where the nodes we work with have 8 bit processors and 4 
kB of memory (we also have nodes with more capacity, but they require 
more battery power). We are considering using XML, BUT the scarceness of 
resources as well as limited battery power makes the overhead of using 
XML to great. We are considering the efficient XML (binary XML), since 
sending and receiving messages is more costly than running a number of 
clocks cycles/instructions to compress the message.

BTW, looking at sales figures, 99% of all sold processors are for 
embedded systems and 1% is for servers, desktop applications, high end 
computing etc (see, for example, 
http://www.ercim.org/publication/Ercim_News/enw52/budde.html). Most of 
these embedded systems processors are at most 8 bit processors.

/Jonas Mellin
> and so on.
>
> To my opinion, none of the above tasks can be done (or easily done) in
> XML based languages.
>
> Whereas XML based languages are specialized to process XML data.
>
> On Mon, Dec 1, 2008 at 9:08 PM, Costello, Roger L. <costello@m...> wrote:
>   
>> Hi Folks,
>>
>> I am exploring the idea of "do all application coding in the XML languages."
>>
>> Here is a response from a colleague:
>>
>> "... in general XSLT is cool but limited. If your transform requires any "higher math" or advanced functionality or external code libraries (such as geometry coordinate system libraries), you almost always have to go back to a higher level language (such as Java) at some point."
>>
>> Does my colleague make a TRUE or FALSE statement?
>>
>> /Roger
>>     
>
>
>
>   


-- 
Carpe Diem!
===
Jonas Mellin, Assistant Professor in Computer Science
School of Humanities and Informatics, Building E-2
University of Skövde, P.O. Box 408, SE-541 28 Skövde, Sweden
Phone: +46 500 448321, Fax: +46 500 448399
Email: jonas.mellin@h..., URL: http://www.his.se/melj


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent