xmlFunctions-34 and compositional semantics (was Re: Agenda of 7 February 2006 TAG teleconference)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd like to offer some thoughts as a preliminary to our taking up the
meat of xmlFunctions-34, to try to clarify a distinction I think is
important.

I think it's crucial to distinguish between what I'll call the "XML
semantics" of an XML document, on the one hand, and the "application
semantics" (or perhaps "namespace semantics") on the other.

The XML semantics of an XML document understood as a sequence of
ISO-10646 code points is determined (nearly*) entirely by the XML
1.0/1.1 and XML 1.0/1.1 Namespaces specs, in a way quasi-formalised in
the XML Infoset spec.  The XML semantics is what you get initially
- From interpreting correctly a message whose Media type is text/xml or
application/(...+)xml.

The application semantics of an XML document understood as an infoset
is determined by the owner of the application.  In the simple case
where all the names in an XML document share a single [namespace
name], the owner of that namespace is responsible for the application
semantics of the entire document.  Mixed namespace cases are trickier.
We'd certainly like it to be the case that appealing to what the
namespace owner(s) have to say should allow you to get at the
application semantics.

In general, the definition of application semantics tends to be
compositional, that is, to take roughly the form of a function which
determines the interpretation of an element with reference only to its
name and the _interpretations_ of its (attributes and) children.

This is the connection with xmlFunctions-34, which I think is
concerned to articulate at least a Best Practice, namely that
application semantics _should_ be compositional, i.e. analogous to a
pure functional language, where the interpretation of e.g.

  (f [expr1] [expr2])

is determined solely by the interpretations of [expr1] and [expr2] and
the definition of f.  Applied recursively, the crucial implication of
this is that the interpretation of e.g. [expr1] is in no way
influenced by its being the first argument of f.

By and large I think we already have this for many spec-defined XML
application, e.g. the interpretation of

     <xhtml:a href="http://www.example.org/...">...</xhtml:a>

is independent of its position in an XHTML document tree.

ht

*I say 'nearly', because it's at least debatable that the xml:base and
xml:id specs contribute to the definition of the XML semantics of an
XML document, and it's at least an intriguing proposition that
XInclude should be understood in a similar manner.
- -- 
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFD6Nk7kjnJixAXWBoRAgMfAJ9ZaS/9wLX50CnnWjCWrRsPBFLNyACeOmJT
qPZZ48XIsvDwRAp78h8j4xg=
=Ag5i
-----END PGP SIGNATURE-----

Received on Tuesday, 7 February 2006 17:30:47 UTC