Stephen,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 HunsbergerOn Mon, Nov 18, 2013 at 7:36 PM, Stephen Cameron <steve.cameron.62@gmail.com> wrote: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.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.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.
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.
SteveOn 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,Hans-Juergen
"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