OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML -- information architect, JSON -- program objects,HTML -- Web browser, DOM -- unwieldy, XQuery -- straddle programming and info architecture

Hi Peter,

Thanks for your comments. I am doing exactly what you are saying and I will read the annotated recommendation as suggested by Michael Kay. However, can I assume that your point is simply that if I ignore all the tools etc that I have as a programmer to work with XML, then as a text document, that can be read by anyone, it still (potentially) has value?

If so, I have no argument with that at all, that: "it is this very decoupling of XML from the way it is represented internally by the systems that handle it that makes XML so flexible."

But my *personal* interest (and the reference to 'Nodists' was an attempt at humour, possibly a lead-balloon?) is the tools that surround XML, which in the cases of XSLT and XForms that I've mainly worked with are based on XPath, are essentially declarative and allow you to work with XML as a hierarchical data-structure. As you write an XSLT stylesheet or XForms form you aren't thinking of DOMs and Infosets, you are thinking of a tree abstraction, of its structure and node names.

If my assumption is correct, here is an attempt to reconcile the two points of view: if you think of an human reading an XML document and a computer parsing it what is the difference? Both essentially are turning a stream of characters into something of value. In the case of the human the interpretation of the stream is a mental process, entirely dependant on the capabilities of the mind of the human, which includes the ability to understand what words and sentences are at the most basic level (structure and meaning), and at a higher level some grasp of both the function of markup and the specific markup encountered(meaning). In the case of a computing machine it is a process mediated by a program (created by the mind of a human), that to me seems essentially the same as the human (but not nearly as capable of grasping meaning I admit), the character stream must be turned into a structure  and then interpreted for meaning. The meaning that given is what I as a programmer have instructed the parser to give it by writing a program, that program enhances the parser essentially (its a data-driven programming style).

Now I agree if I have parsed XML documents in an XML database I no longer have it in a text form, the parsing has been done and its been turned into an internal representation with persisted structure, but aren't I then just working with it at the second stage of trying to extract meaning (information) from data?


On Wed, Nov 20, 2013 at 3:42 AM, Peter Hunsberger <peter.hunsberger@gmail.com> wrote:

although I won't quibble with the overall architectural design you set out I really can't see why anyone here is pushing XML as a "data structure".  For data, XML is a serialization format, mostly a way to get bit's and bytes exchanged between systems.  Those other systems might in turn convert the XML into a data structure, or those systems might save XML as an opaque blob, but that's a process performed on the XML and not part of the XML itself.

I do understand the temptation to view XML as having some form of structure, and as a serialization format (and a document format) it needs to have a standardized way of being interpreted.  However, one needs to resist the temptation to confuse the book with the information contained inside the book.  (As a data modeler I fall into that trap on a regular basis in spite of having started with SGML when data transport wasn't even really considered.) There are portions of the XML tool set that build elements and nodes and trees and what have you, but those are internal to the applications handling the XML.  The DOM and Infoset models do nothing to relieve the confusion -- they probably give life to it -- but I think if you examine them carefully you will see that they claim, at best, to represent an interpretation of XML and are not in and of themselves XML.

Yes, it's a thin semantic line that I'm drawing here, but it's an important one; as others have pointed out here, it is this very decoupling of XML from the way it is represented internally by the systems that handle it that makes XML so flexible.

Peter Hunsberger

On Mon, Nov 18, 2013 at 7:36 PM, Stephen Cameron <steve.cameron.62@gmail.com> wrote:
Hi Hans,

As one 'Nodeist' to another I have a different take on what is important. My vision is that when building systems the first option that is considered is a non-object-oriented one based largely on generic infrastructure. A system that is largely based on XML Technologies, but presented to users via appropriate interfaces so they can configure the infrastructure to their needs in a reasonably "fool-proof" manner.

If more than simple configuration is needed then programmers might be employed to write some XQuery code, but making use of the pipeline metaphor in which standard components are pieced together with custom components.

Then, if the behaviour of the required system is even more complex, it might be considered necessary to make use of an object-oriented language to build the system, but thinking of OO more in the way it was originally conceived, as a modelling tool to enable complex systems to be achievable within the limitations of human cognitive (conceptual/social/organisational) abilities.

In this vision, XML is an highly flexible hierachical and *generic* data-structure (its SGML roots?), which allows it to be processed using generic tools, based on the Path and Event concepts, that are language independant essentially.

To my mind these are two distinct approaches, each with particular strengths, but capable of co-existing and even complementing maybe (your take on it).

I can think of three reasons that this data-driven infrastructure ('XML-ish') approach might be good:
(1) Its likely to be significantly cheaper to implement, for the right kind of use.
(2) Its likely to allow system users, rather than programmers, to take a more active role in putting it together and maintaining it.
(3) It fits with the idea of data having a longer life than programs.

As some evidence of the logic of this viewpoint, I take the existence of things like rules-engines and workflow design tools in the OO world, that, to my mind, are more appropriate to the data-driven infra-structure approach.


On Sun, Nov 17, 2013 at 1:06 AM, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:
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:
For an example what kind of code the X-developer needs to provide, see here:
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:
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,

"Costello, Roger L." <costello@mitre.org> 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@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS