Re: [xml-dev] Re: Native XML Interfaces

[Peter Flynn <peter@silmaril.ie>]

On 06/03/2013 12:30 PM, Timothy W. Cook wrote:
> On Mon, Jun 3, 2013 at 8:12 AM, Andrew Welch <andrew.j.welch@gmail.com> wrote:
>>> But Andrew, maybe I include myself in that category of not being aware
>>> of the APIs that are available. Could you exand on that with a couple
>>> of examples?
>>
>> For example the dev is faced with the challenge of extracting the
>> <title> and product/@id values from some xml.
>>
>> They could:
>>
>> - use xquery/xpath
>> - use xom/jdom
>> - use sax/stax
>>
>> instead they use a tool to generate an xsd from the xml, then use a
>> binding tool to generate some classes, then use those generated
>> classes.
> 
> Okay, thanks.  Maybe I won't include myself in that group then.  :-)
> That is REALLY going the long way around.

It's not that far removed from database engineers whose worldview
includes SQL, period. Their solution to adding 2+2 is to create a table
with two fields, populate them with the value 2, and then write a stored
procedure to query it, extract the values, and add them together.

There are real-life examples of this I am sure we could all share;
perhaps at an evening session at Balisage :-) but it's not just an
education problem: it's both conceptual and perceptual.

The dev|eng|prog or whoever (remember the DPH?) has a set of working
tools, as we all have in our own field. Their perception of information
and information-manipulation problems -- and ours -- is conditioned by
their familiarity with their tools ("Nail Hammer Soup", as Len said) and
with the types of information they regularly deal with.

Introduce pointy brackets, and you are adding a new concept for which
they have no tools. Provide training, and they will see that there are
tools to deal with pointy brackets. But unless you also deal with the
connection between conceptualisation and perception, they will still see
the pointy-bracket world as another, perhaps interesting, parallel
universe to the one they regularly work in. The only connecting tissue
is the information itself.

"Getting" XML involves a different way of conceptualising information
for them. For people who work in the rectangular-data world, where
everything is a table, XML consists of two object types: elements in
element content, and character data (read: fields and values).  The
messy and infinitely plastic world of text documents and mixed content
and recursive nesting just looks to them like a cat got a fright in
their database schema.

If you then try to extend "getting" XML to the ordinary author (my own
hobby-horse) who is *not* a dev|eng|prog|dph but a professional
equivalent in another field (a chemist, perhaps, or a political analyst,
or an accountant, or even a PHB), there is a great deal of uncommon
ground which is simply missing in their experiences. They have a screw,
but they have never come across a hammer, let alone a screwdriver; in
fact they only have a child's toy for making farm animals from
modelling-clay.

There are lots of paradigms for native XML interfaces, and we here are
all in a position where we could adopt or adapt them to do things the
way we want, pointy brackets and all. Many of us do this already, some
of us for a living. But THE challenge is to make a native XML interface
that the wordprocessor user with a requirement to generate
semantically-reusable XML can use without being aware of it. That means
NO pointy brackets in sight. Ever. Really.

Most documents (and users) in the Real World[tm] don't need this: the
documents are transient or ephemeral, and a wordprocessor or wiki/CMS
editor will do just fine, even one which uses XML to store the ephemera.
For some value of "most" -- my gut feeling is around 98%. For the rest,
there are some things that can be done to adapt the interface: Xopus has
already implemented a few of them. The real question is, is that 2% big
enough numerically to justify the investment for a business to do the
job and do it right? Or for an Open Source project to take it on?

///Peter