Re: [xml-dev] XML vocabulary for expressing constraints?

[Steve Newcomb <srn@coolheads.com>]

On 12/14/2013 08:07 PM, Hans-Juergen Rennau wrote:
> Steve, thank you very much for this excursion into the land of property
> sets! I am fascinated by the boldness of providing a generic addressing
> language (property sets) applicable to arbitrary data formats, without
> making any assumptions about the underlying data models. I suppose the
> key concept is to associate within-resource locations with properties,
> and to base within-resource navigation on property matching. And I
> further suppose that for each pair (format, property set) there must
> exist a specific software component corresponding to an XPath processor
> which resolves "property set expressions"  to sub resources. Yes? No?

Yes.  That's the idea, anyway.

> I am thrilled by your statement:
> "To summarize, the space you're talking about is a subspace of a larger
> space that includes
> non-XML information, and in which XML may yet play a fantastically
> important integrative role.  From my personal perspective, the subspace
> you're thinking about is the part of the larger space that happens to be
> rooted in the SGML Property Set."
>  
> It matches my thinking in a particular way: I agree that we should
> discover the larger space of which XML is a sub space - a universal info
> space. In your thinking this may be achieved - at least conceptually -
> by a step of generalization: from the XML-specific property set
> underlying XPath (with its key properties [node-name], [children],
> [parent], [attributes]) to the abstract concept of property sets; and
> subsequent steps of instantiation, one per non-XML format to be
> considered. Or am I mistaken?

Only two corrections:

(1) It wasn't my thinking.  From the ringside perspective I had at the
time, it was James Clark's awesome insights, and Charles Goldfarb's
articulate insistence on what he saw as the requirements to be
fulfilled.  My contribution to that work was to drive James between his
hotel and Charles's house in Saratoga, and otherwise mostly to witness.
 It was hard for me to follow the conversation, frankly, and it made me
so tired I had to lie down on Charles's dining room floor at times.  The
full outrageous significance of it didn't completely dawn on me until
later, when I could study and reflect on the finished product.

(2) Not *one* property set per notation.  N property sets per notation,
where N > 0.

> Whether feasible or not, I think this would not give us the navigational
> uniformity attained by "XPath everywhere". And therefore I advocate an
> alternative generalization: the transition from regarding XML as a
> syntax backed by a data model, to regarding XML as a data model backed
> by syntaxes one of which is XML.

(Not a new idea, of course.  SGML syntax, most of which endures in XML,
is the syntax everyone loves to hate.  I can't count the number of
diatribes and proposals for fixes and alternatives I've seen, some of
them quite good.)

> (Perhaps it is too much of a shortcut
> to call the data model XML, an alternative would be UDL - Unified
> Document Language).

I see what you're saying, but your use of the term "data model" makes me
shudder.  There are wildly conflicting dogmata and convictions about it.
 In my standards-making experience, the use of that term leads straight
to confusion and consternation.  I wish it were useful, though; it's
such a nice term.  I, at least, know what it means, and it's so
well-defined, hahaha.

> This amounts to a change of paradigm: document text
> (XML, HTML, CSS, JSON, CSV, SQL, Turtle, ...) is an expression whose
> value is an instance of the data model.

Note that a property set is emphatically not a data model, at least as I
understand that term.  Is an XML schema a data model?  As one formulates
an answer to that question, one tends to lose track of what XML is all
about.  It's emphatically not about implementations, although most
system vendors, including historically influential members of the W3C,
would prefer that it were.  It's about information interchange.  To lose
sight of that is to invite a repetition of the history that motivated
the development of XML nee SGML.

> The expression-oriented thinking
> of XPath/XQuery/XSLT would be extended and applied to the resources
> themselves. 

What is "expression-oriented thinking", as opposed to any other kind of
thinking?

> The reward would be a homogeneous substrate of information
> (homogeneous content clothed in heterogeneous syntax), supporting a
> uniform navigation model (XPath) and uniform processing models (XQuery,
> XSLT, XProc, ...).

It sounds great, but I don't get it.  It seems to me that different
notations require different modes of thought in order to address their
components elegantly (or even usably).  Even a single notation may have
multiple useful ways of thinking about it.  To paraphrase Wittgenstein,
"To imagine an addressing language is to imagine a way of life."  XML
implies a hierarchical tagged-and-attributed way of life that is not the
same as, e.g., the way of a graph database, a programming language, a
notation for images, a musical score, etc.

By the way, historically speaking, the property set idea is the real
root of the topic maps idea.  The idea was to open up the property set
idea "all the way", so that not only information components could be
addressed, but *any* subjects of conversation could be addressed.  I
intended Topic Maps to develop into a metalanguage for generalized
addressing.  Instead, as amended and in common practice, it became a
data model.  I'm still struggling with the lessons of that history.