Roger, I think we need a novel concept of *integrating* XQuery/XSLT into general purpose languages like Java. I propose the following basic principles (using Java as an example language; the term “xtool” denotes a piece of functionality provided using native XML technology, e.g. XQuery, XSLT, XProc). So…

(a) the client thinks in terms of xtools - providers of functionality, identified by a name and defined in terms of a signature; he need not know the actual implementation language of the xtool

(b) the input is provided in the caller’s native format (e.g. as arrays or Properties objects)
(c) the result is delivered in the caller's native format (e.g. as arrays and Properties objects)

 

The guiding principle is that the caller delivers input as he is used to deliver input to native components, and he receives results as he is used to receive from native components.

 

What is required to implement this scenario is a modest piece of infrastructure: a layer translating (a) between the native input supplied by the caller and XDM input actually required, (b) between XDM output actually delivered and the native entities expected by the caller.

 

The translation of xtool results into Java entities is controlled by “annotations” – XDM items which are part of the result XDM sequence. So the XDM result is composed of primary items providing the data themselves, and “meta items” directing their assemblage into the client’s native entities and associating these entities with names.

 

What is handed back to the client is an “info tray”, a generic interface offering name-based access to the various parts of the xtool result.For an illustrative example how this looks from the Java programmer's perspective, see this code snippet:

 

http://www.balisage.net/Proceedings/vol5/html/Rennau01/BalisageVol5-Rennau01.html#d126110e307

 

For an example what kind of code the X-developer needs to provide, see here:

 

http://www.balisage.net/Proceedings/vol5/html/Rennau01/BalisageVol5-Rennau01.html#USGS-evaluation-query

 

This was a rather dense account of the concept, but I hope the idea has emerged. If somebody is interested, he can find the details here:

 

http://www.balisage.net/Proceedings/vol5/html/Rennau01/BalisageVol5-Rennau01.html

 

And this is the gist of my posting: an innovative integration of XML technology into Java & co is possible and it is EXTREMELY important to the future of XML technology. However, it requires a change of minds: it requires a genuine interest in integration. The rest is a little diligence.

 

The way things should be: XML technology acts like a service to Java & co; ordinary developer teams include a couple of X-programmers who provide xtools according to the requirements handed in by the general purpose language programmers. My vision: XQuery & co. as ubiquitous as Java, but not standalone: embedded in general purpose language systems.

 

Kind regards,

Hans-Juergen

"Costello, Roger L." <costello@m...> schrieb am 11:32 Samstag, 16.November 2013:

Hi Folks,

The words below from Liam Quinn deserve to be in the xml-dev Hall of Fame. Brilliant insights Liam!

----------------------------------------------------------
On November 15, 2013 Liam Quinn wrote
----------------------------------------------------------
When you design an XML vocabulary, you are in control. You own your own data format. You are an information architect.

When you use JSON, you are often in the role of a programmer, an application designer, and the JSON format you design is a reflection of the objects in your program. The program owns the data.

When you use HTML, you are using a vocabulary designed primarily by Web browser people, and the Web browser is primary, not your data.

XML frees your information from being optimized for, and specific to, any one program. But the consequence of this is that it is not as convenient for the programmer. So programmers tend to dislike it.

Further, programmers were forced early on to use the DOM to work with XML, and this was so unwieldy that almost anything else was better.

XQuery is so interesting because it straddles all the worlds. Where the XML DOM takes the programmer-unfriendly aspects of XML and forces the programmer to deal with them, XQuery hides many of them.

But for now at least yes, many programmers have good reasons to dislike XML, and it helps all of us in the XML world to understand these reasons.


_______________________________________________________________________

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