Acknowledgements

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

The f(X) 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
• f(X) takes a different approach
  • allowing XML documents to indicate their own preferred processing

f(X) 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
    • Schema component graph
  • RDF
    • A graph
  • SVG
    • A collection of displayables
• The f(X) 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

Signalling computed infosets

• What kind of semantics do we find for these ad-hoc signals?

  xsi:schemaLocation

  Validate me [and use the resulting PSVI]

  xml-stylesheet

  Transform me [and use the result tree]

  http://www.w3.org/2001/04/xmlenc#

  Decrypt me [and use the resulting infoset]

The f(X) approach

• Existing signalling mechanisms are neither systematic nor universal
• f(X) is uniform and extensible
• f(X) has two parts
  1. An infoset-mapping self-describing interpretation for elements in the f(X) namespace
  2. [censored]

Introducing basic f(X)

• Elements in the f(X) 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.

The power of f(X)

• The potential for composition is where f(X) 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

f(X) unchained

• The outline of a simple functional language is emerging.
• Actually wrapping existing XML documents with f(X) 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
• Because the use of XInclude purely to provide external input is going to happen a lot, we provide a shorthand
  • Indirection with fx:included: Same as first example - Decryption of a document
• fx:included allows us to separate the statement of intended or desired designation from the core document
  • but does not require it.

Summary of f(X) so far

• f(X) specifies the designation of three basic classes of XML elements:

  fx:included elements

  Designate the result of first interpreting the href, xpointer and other XInclude attributes per the XInclude spec.

  other elements in the f(X) namespace

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

  all other elements

  Designate themselves/their ordinary infosets, except in-so-far as they contain elements in the f(X) namespace, which are interpreted per the above two clauses.

Completing basic f(X)

• A few things need to be added to cover the intended basic functionality
  • A means to prevent the special treatment f(X) specifies for the first two classes of elements
    • We provide the fx:sic element for this purpose
      • Quoting: designates a single-element (fx:included) 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 fx:result (XSLT) we allow a stylesheet attribute or a second child to name or directly provide the stylesheet.
  • For fx:PSVI we allow a schemaDocuments attribute and/or multiple children
    • Multiple args 1: Using children.
    • Multiple args 2: Using attributes.

Initial inventory of f(X) elements

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

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

Beyond basic f(X): Choosing

• Some existing pipeline languages allow for conditional processing.
• We can do this in f(X) if we want
  • Using XSLT's choose as a model
  • Like this:

    <fx:case>
     <fx:when test="boolean-valued XPath expression">
      infoset to test
      result infoset if test succeeds </fx:when>
     . . .
     <fx:otherwise>
      result infoset if no test succeeds
     </fx:otherwise>
    </fx:case> 

  • fx:case example Choosing a schema depending on version

Beyond basic f(X): Binding

• The previous example reveals a weakness
  • No way to share an infoset
  • Even if it takes a lot of work to build
  • And is needed more than once
• We could hope that implementations will detect and optimise
• Or we could provide a binding mechanism
• Binding actually makes f(X) documents easier to understand
• We use fx:with to scope bindings
  • fx:variable to bind
  • and XPath variable references or fx:infoset element to refer to bindings

Binding, cont'd

• Variables can be bound to constructed infosets, or via URI references:

  <fx:with>
   <fx:variable name="var name">
    f(X) designating an infoset
   </fx:variable>
   <fx:variable name="another name
                href="URI for infoset"/>
   . . .
  </fx:with>

• fx:with example Same functionality as previous (conditional) example
• Illustrates both kinds of variable reference
• This opens the door to potential complexity problems
  • Care has to be taken not to inadvertently allow recursive processing

Implementation strategy

• Implementations are already available for a number of ODTAO pipeline languages.
• It is straightforward to translate basic f(X) into any of these.
• fx:case and fx:with are a bit trickier. . .

Conclusion

• f(X) 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
• f(X) is a new idea
  • Feedback is very welcome