Functional XML

1. Acknowledgements

The work reported here was initiated by an idea of Tim Berners-Lee, who also first used the phrase "functional XML" in my hearing. The basic direction was first suggested by Richard Tobin.

2. The functional perspective on XML

• XML is sometimes called 'self-describing'
• Mostly this is trivial
  • Elements and attributes have readable names
• It can be more substantial
  • When an XML namespace is given a clear semantics
• Many XML standards supply a functional semantics
  • That is, they can be understood as specifying a mapping from infosets to infosets.
• Hence the growing interest in specifying XML (infoset) pipelines
  • Sun's original W3C Note
  • Markup Technology's MT Pipeline
  • Sean McGrath's XPipe
  • Norm Walsh's SXPipe
  • Orbeon's XPL
  • 1060 Research's NetKernel

3. The λ-XML approach

• All those existing pipeline languages have ODTAO semantics
  • A pipeline is a document
    • which specifies a sequence of operations
    • to be executed one after another
    • on other documents
  • For example
• λ-XML takes a different approach
  • allowing XML documents to indicate their own preferred processing

4. λ-XML namespace semantics

• The superficial semantics of an XML document is its own XML infoset
• Some XML namespaces specify an underlying semantics in the form of an abstract object model
  • XML Schema
    • Its PSVI
  • RDF
    • A graph
  • SVG
    • A collection of displayables
• The λ-XML namespace specifies its underlying semantics in the form of a further infoset.
• With hindsight we can see in some existing specifications versions of this approach
  • the xsi:schemaLocation attribute on a document element
  • the xml-stylesheet processing instruction
  • the http://www.w3.org/2001/04/xmlenc# namespace

5. The λ-XML approach

• Existing mechanisms are neither systematic nor universal
• λ-XML is uniform and extensible
• λ-XML has two parts
  1. An infoset-mapping self-describing interpretation for elements in the λ-XML namespace
  2. A shorthand notation for λ-XML documents based on the λ-calculus and Scheme

6. Introducing basic λ-XML

• Elements in the λ-XML namespace specify an infoset-to-infoset mapping
  • Their names typically describe the output of that mapping
    • That is what they are to be understood as designating
  • In the simplest cases, their input is the infoset designated by their single child element
• Taking the schema validation and decryption as our starting point, we get the following examples
  • decryption: designates the infoset resulting from decrypting the ciphertext and parsing the resulting stream as XML.
  • schema validation: designates the post-schema-validation infoset resulting from schema validity assessment of the basic infoset corresponding to the purchaseOrder element.

7. The power of λ-XML

• The potential for composition is where λ-XML clearly moves beyond the existing ad hoc signalling mechanisms
• Wrt validation and decryption, either order makes sense
  • composition 1: PSVI of decrypted document
  • composition 2: Decryption of schema-validated document
• Indeed validation both before and after decryption is probably often what is wanted:
  • composition 3: PSVI of decryption of schema-validated document

8. λ-XML unchained

• The outline of a simple functional language is emerging.
• Actually wrapping existing XML documents with λ-XML elements won't always work
  • Not local
  • Read-only
  • Multiple designations wanted
  • . . .
• XInclude to the rescue!
  • Indirection with XInclude: Same as first example - Decryption of a document

9. Summary of λ-XML so far

• λ-XML specifies the designation of three basic classes of XML elements:

  elements in the λ-XML namespace

  Designate the result of the mapping specified by their name applied to the designations of their children.

  elements in the XInclude namespace

  Designate the result of processing themselves per the XInclude spec.

  all other elements

  Designate themselves/their ordinary infosets.

10. Completing basic λ-XML

• A few things need to be added to cover the intended basic functionality
  • A means to prevent the special treatment λ-XML specifies for the first two classes of elements
    • We provide the λ:sic element for this purpose
      • Quoting: designates a single-element (xi:include) document.
  • More than one input infoset and/or parameterisation of some kind
    • Use attributes on the mapping element for parameters
    • Use additional children for multiple inputs
    • Allow attributes for additional inputs as well
  • So for λ:result (XSLT) we allow a stylesheet attribute or a second child to name or directly provide the stylesheet.
  • For λ:PSVI we allow a schemaDocuments attribute and/or multiple children
    • Multiple args 1: Using attributes.
    • Multiple args 2: Using children.

11. Initial inventory of λ-XML elements

• There should be built-in λ-XML designators for each public specification which can be understood as defining XML-to-XML functions.
• Here's an initial list

  λ:valid	Validated W3C XML
  λ:PSVI	W3C XML Schema
  λ:result	W3C XSLT (v.1 or v.2, depending on stylesheet)
  λ:queryResult	W3C XML Query
  λ:encrypted	W3C XML Encryption
  λ:decrypted	W3C XML Encryption
  λ:signed	W3C XML Signature
  λ:verified	W3C XML Signature
  λ:transcluded	W3C XML Include
  λ:gMeta	GRDDL

12. Namespace or programming language: Compact notation for λ-XML

• 'Compact notations' for XML languages are in fashion
• A functional namespace deserves a functional notation
• For λ-XML we use Lisp, specifically Schema, as our model
  • As the original computational manifestation of the λ-calculus
• We need just three correspondences to get started:
  • Function applications of names in the λ-XML namespace correspond to elements
  • A double-quoted string S corresponds to <xi:include href=S>
  • <-delimited XML corresponds to itself
• First five examples in compact form

  (λ:decrypted <EncryptedData ... </EncryptedData> )
  (λ:PSVI <purchaseOrder . . . </purchaseOrder> )
  (λ:PSVI (λ:decrypted <EncryptedData ... </EncryptedData> ))
  (λ:decrypted (λ:PSVI <EncryptedData ... </EncryptedData> ))
  (λ:PSVI (λ:decrypted "encrypted.xml"))

• When the full form makes extensive use of xi:included material the compact notation wins big

  (λ:result (λ:PSVI "po.xml" "address.xsd" "po.xsd")
            "po.xsl"))

13. Inspirations from Scheme -- Conditionals

• Conditionals can use XPath expressions to test infosets
  • and choose results based on the outcome
• How to determine what infoset is being tested?
• Option 1: Use a λ:test expression:

(cond ((λ:test "po.xml" [/root/@version > 3])
           (PSVI "po.xml" "current.xsd"))
       (true (PSVI "po.xml" "stale.xsd")))

• This seems un-necessarily verbose
  • if taken literally would involve the inclusion of the "po.xml" document twice

14. Better conditionals, with binding

• Adding binding as well allows a simpler approach:

(let ((doc "po.xml"))
 (cond ([$doc/root/@version > 3]
           (PSVI $doc "current.xsd"))
       ([true] (PSVI $doc "stale.xsd"))))

• XPath variables can reference let-bound variables
• We write let and cond, not λ:let and λ:cond
  • because these are "special forms", not proper functional expressions
    • Although there are straightforward-enough translations into pure functional terms, these are somewhat verbose and unwieldy to work with

15. Inspirations from Scheme -- Mapping

• Mapping with replacement, i.e. mapcar, is another attractive feature
• The corresponding function that suggests itself for λ-XML has three arguments
  1. an XPath expression to select sub-documents
  2. a function to apply to each matching sub-document
  3. an infoset to map through

(λ:mapped [item/price]
         (λ (subdoc)
           <amount currency="USD">
            <xi:include href="#subdoc"/>
           </amount>)
         "po.xml")

• We us a λ form in the usual way
• Variables bound with let or λ can be accessed
  • by variables in XPath expressions
  • by local barename-only URLs
• Another parallel with Scheme
  • raw XML is not so much quoted
  • rather it's back-quoted
    • with the resumption of evaluation signalled by
      • xi:include
      • elements from the λ-XML namespace

16. Possible further extensions

• Even back-quoted XML won't always be sufficient
  • And full XSLT via λ:result is a bit heavyweight for many purposes
• Something which applies an XSLT template to every matching sub-document might be very useful:

(λ:templateApplied
 <xsl:template match="item/price">
  <amount currency="USD">
   <xsl:apply-templates/>
  </amount>
 </xsl:template>
 "po.xml")

• Another thing we will want eventually is try/catch.

17. A note about media types

• λ-XML needs the registration of two media types
• Their definition will require documents of those types to be interpreted appropriately

  text/lx

  For documents in the compact notation

  application/lx+xml

  For XML documents in the λ-XML namespace

18. Implementation strategy

• Implementations are already available for a number of ODTAO pipeline languages.
• It is straightforward to translate basic λ-XML into any of these.
• let and cond are a bit trickier. . .

19. Conclusion

• λ-XML faces two directions at once
  • It's a novel approach to self-describing XML
    • And an alternative to ODTAO pipelines for specifying XML processing
  • It's a candidate for a programming language whose primary data objects are XML documents
    • Focussed at the opposite end of the scale as compared to XQuery, XMLambda or Links
• λ-XML is a new idea
  • Feedback is very welcome