Costello, Roger L. a écrit :
> I am exploring the idea of "do all application coding in the XML languages."

This is the job of Active Tags and RefleX :) http://reflex.gforge.inria.fr/

Let's take XSLT, XProc, OASIS Catalogs, Ant, W3C XML Schema, etc.
Each can be considered as a declarative language (made in XML) that 
serves a specific purpose.
Their strength is that they are declarative, they focus on "what" rather 
than "how-to"; that makes them consise and expressive but limited to 
what they are designed for.
They need a specific processor for running or interpreting "scripts"

XQuery is different since it doesn't rely on an XML syntax (XQueryX 
does); it's not really important except if you consider new instructions 
(such as the XQuery Update Facility) that extends the language: you have 
to patch the grammar, and it's more easy if it's XML (compare to XSLT 
that you could be extended with custom instructions such as <sql:select> 
without touching the XSLT processor if it has been designed for 
extensibility); it would be more easy to inject foreign instructions in 
XQueryX than in XQuery (the other question would be: "where ?"). So, 
XQuery is not so extensible, of course you can write functions and 
libraries, but it doesn't have any sense to use XQuery as a starting 
point to design -say- a schema language, or one of the XML languages 
mentionned before (I don't say it's impossible, I just say it would be a 
fool idea to do so with XQuery).

Therefore, we can't inject new instructions to the language at no cost, 
like it was done with XQuery and XQuery Update Facilities. What will be 
the next XQuery extension ?
On the opposite, XSLT, XProc, OASIS Catalogs, W3 XML Schema, etc are 
predisposed to extension because they rely on pure XML.

XML for processing purpose:
-is good for hosting templates (XML fragments of data)
-is good for designing declarative languages
-is good for extending a language, or better, mixing languages (why 
should we consider that there is a master language (XSLT in my example) 
and extensions to that language (<sql:select> in my example) ?)

My last remark lead to the following consideration: XML languages 
designed for processing purpose don't rely on a common engine (although 
they could because they are all working in the same manner), and 
implementors have to deal with low-level problematics again and again 
(how to unmarshal the elements to their concrete implementations, how to 
bind and process datas at runtime, etc) with each time a specific 
solution and an incompatible implementation; the <sql:select> extension 
for my XSLT processor won't be usable with my XProc processor; moreover, 
the guy that will design such extension for XProc will invent probably 
an element with another name <sql:query> (with another namespace), other 
attributes, and that lead to another result. One more example: how many 
XML instructions have been designed that represent an alternative 
instruction (if-then-else statement) ? <xsl:if test="...">, <scxml:if 
cond="...">, <xproc:when test="...">, <xs:alternative test="...">, etc

Don't you think that it's time to design a common framework for 
XML-based processing ?

Current (partial) solutions:
-Templates langagues for the Web (such as JSP): are dedicated to a Web 
environment (tightly coupled to things such as an HTTP request, a web 
session, etc) and usable only in a specific platform (Java in the case 
of JSP)
-General-purpose framework like Jelly: XML scripts usable only for 
imperative processing (would you be able to design a schema language 
with Jelly ? Of course, not at all) and not so close to XML 
technologies: they rely on UEL (related to Java) instead of, say, XPath 
(not related to anything particular, except perhaps with XML...)

What I tried to designed with Active Tags and RefleX, is such a 
general-purpose framework:
-not related to any particular language (although my implementation is 
available in Java, others could be in another language/platform)
-you can design declarative languages with it (I designed a schema 
language called the Active Schema Language)
-you can write scripts that mix imperative languages with declarative 
statements
-you can run it in batch (from the command line) or within a Web application
-you can query various data sources: RDBMS with SQL, XML native 
databases with XQuery, LDAP directories, ill-formed HTML documents, etc
-you can use XPath to handle non-XML objects
-etc

The last point is interesting: most people tend to consider XML data 
binding technologies for using XML in OO environments; I prefer 
considering XML on top of OO environments and expose objects with XML 
characteristic: for example, it's very useful to handle a directory from 
a file system with XPath to extract a set of files: $myDir//* will 
browse the entire subdirectories, and since file objects are exposing 
their properties as XML attributes, you can of course use predicates: 
$myDir//*[@io:size < 1024] for example.
Some people in this thread already mentioned that some XML native 
processors can be good when the data to process is also XML; I would 
like to add: or when it can look like XML. Exposing some arbitrary 
objects like XML is in many cases much more convenient than creating a 
real XML structure (sometimes, it's better to avoid cost round-trips 
to/from XML).

An XML-centric environment like Active Tags is certainly extremely 
valuable for people that have to invent new XML declarative languages 
(there are so many to come).
An XML-centric environment like Active Tags requires a knowledge of XML 
technologies, at least XSLT I think.

I talked at Balisage 2008 about the ability to mix declarative languages 
with imperative constructs (with a focus on XML schemas):
"Properties of schema mashups: dynamicity, semantic, mixins, 
hyperschemas": 
http://www.balisage.net/Proceedings/html/2008/Poulard01/Balisage2008-Poulard01.html
slides:
http://hal.inria.fr/docs/00/32/26/61/ANNEX/Bal2008poul061003.pdf

You can also download and play with the engine:
http://reflex.gforge.inria.fr/
if you want to write XML scripts (that are not necessarily related to 
schemas)

I do believe in XML-native processing. I just complain that there are so 
much engine that are ignoring the others.

-- 
Cordialement,

               ///
              (. .)
  --------ooO--(_)--Ooo--------
|      Philippe Poulard       |
  -----------------------------
  http://reflex.gforge.inria.fr/
        Have the RefleX !

_______________________________________________________________________

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