Work in progress This version may be updated without notice.

1 What is Active Tags ?

Active Tags is a set of specifications that allows to describe processes with tags. Such an entire process, called an active sheet, may be procedure centric, declarative centric, or both, according to the tags used and what they are intend for. Tags are designed to perform actions that cooperate to produce the expected results. For this purpose, properties ruled by a data model may be handled by theses tags. A family of tags, attributes, functions, predefined properties and data types are grouped in a module. Each module is independant from the others, but properties created by a module at runtime may be used by other modules because they share the same data model. Furthermore, nested tags may also cooperate even if they are not part of the same module. Each module is responsible of its tags usage. It is highly recommended that users define their own module for special purpose processing. Thus, any custom complex operation may be exposed as a single tag.

Active Tags is primarily designed to deal with XML technologies, but may be used also for many other purpose, according to the role of the modules involved and their relevant features. Active Tags uses itself XML technologies and concepts intensively, such as :

• XML : an active sheet is an XML document...
• XML namespaces : each module is identified with a namespace URI...
• QNames : anything that has a name in Active Tags is a qualified name...
• XPath : properties are handled thanks to XPath expressions...
• ...

This specification describes the standard behaviour of an engine that implements the Active Tags specifications, what modules are, how to design them, and how to use them. Additionaly, the mechanism that loads module is also specified in this document. The data model is detailed : how to create objects, how to manage them in collections, and how to handle them. Finally, the core modules are introduced :

• EXP (Extensible XML Processor) : a module used for bootstraping when default behaviours are undesirable, used for invoking external active sheets, used to tune a single active sheet, or used to bind the module materials to their concrete implementation.
• XCL (XML Control Language) : a module that defines procedural features such as alternative and iterative processing, XML features such as XML parsing and XSLT transformation, and Active Update features.
• ASL (Active Schema Language) : a powerful schema language built on Active Tags; ASL is able to express assertions that other schema technologies (DTD, W3C XML Schema, Relax NG, Schematron) can't express. ASL may be used as a standalone schema technology, as a meta-schema able to mix assertions defined in other schema technologies, or in the opposite as a fragment-schema to define single assertions.
• Active Datatype : a data type library (grouping several modules) that covers usual data types expected in Active Tags related technologies such as Active Schema. Active Datatype also provides an adaptation of W3C XML Schema data types to Active Tags requirements.
• Active Catalog : an XML Catalog enhanced with the Active Tags capabilities.
• the inner fallback module : an internal module used when a tag is not bound to a module, that allows to produce an inline XML structure; this module is also involved when a dynamic XML document contains snippets Active Tags code.

1.1 The processing instructions

SGML and XML came with a structure called processing instruction (PI) that allows applications that read XML documents to react when such structure is encountered. Notice that the datas stored in PIs are not usually considered as content, and shouldn't be used to store significative information.

This structure suffers of many defaults :

• namespaces don't apply to PI's targets, so, collisions may happened (an application could wrongly react on a PI)
• PIs are poorly structured, the best effort is to consider the PI's datas as attributes (conventionally called pseudo-attributes)
• PIs can't be nested

In a certain way, PIs are used to perform a specific action by a given application.

Consider now that, instead of using PIs, one uses a specific qualified element :

• by using a qualified name, an application knows that it is really for it, or not
• as other elements, attributes are real attributes
• instructions may be nested, and complex processing may be described

Active Tags handles tags for processing. However, unlike XML PIs, the active tags may be structured like XML elements (they are XML elements !).

Another programming language ?

Although the XCL specification describes a set of tags used to perform oriented-procedural processes (XCL is an imperative language, in the sense that it consist of a sequence of commands), Active Tags is not properly a new programming language. Actually, tags may be designed as well in a declarative way ; declarative sentences allow to achieve complex processes at runtime which are exposed in a very concise manner. However, as declarative sentences may be very useful in certain cases, they are also often limited : when the limit of a declarative model is reached, Active Tags allows to switch to an imperative model.

The power of Active Tags is to allow a mix of declarative sentences with procedural processes in an XML way.

In this way, Active Tags defines a framework for XML Native Programming.

A schema written with ASL and XCL is a concrete example of a language that deals simultaneously with procedural processes and declarative-based processes.

1.2 The federation of the XML technologies

XML technologies are dealing with heterogeneous mechanisms all along the XML chain process. This mechanisms which are taking part to a specific process or behaviour are often part of the XML instance. For example :

• the <!DOCTYPE> declaration,
• the standalone pseudo-attribute,
• the xsi:schemaLocation attribute,
• the <xi:include> element,
• the <?xsl-stylesheet?> processing instruction,
• etc

Another black point with this mechanisms, is that they must be repeated within each instance of the same class. When one of this process evolves, for example when upgrading from DTD to W3C XML Schema, all instances of the same class must be updated.

Active Tags allows to externalize in an homogeneous way the XML chain process, and allows anyway to embed in XML documents special purpose processing (such documents are called Active Documents in this specification). By describing processes in an XML way Active Tags becames the unifying element of the XML technologies. In addition, Active Tags is taking its place as the main bridge between XML and other technologies.

1.3 How to use Active Tags ?

Active Tags defines a generic way to describe processes in XML.

Active Tags relies on XML and is independant of any system, language, or architecture. This last point makes Active Tags usable in various contexts such as :

• batch processing
• web embedding
• client/server
• etc

According to the chosen architecture, an engine which implements the Active Tags specifications might be invoked :

• by the internal Active Tags invokation mechanism (EXP)
• by the command line
• by an application which embeds the engine
• by a web application
• by a plug-in within a web browser
• by an end-user application with a graphic user-interface
• etc

The data processed could be :

• XML files stored in a file system
• XML documents stored in an XML native database or in a Document Management System
• XML flows produced on the fly and taken for example from an RDBMS or an LDAP directory
• any non-XML data source
• a mix of these structures

Finally an engine which implements the Active Tags specifications may be used :

• client side
• server side
• both

When an active sheet is designed to run on a specific architecture, specific modules may be used to deal with related features provided by this architecture. For example, a web module could be designed to process easily HTTP requests and formatting HTTP responses. Furthermore, it may be advantageous to define modules that are language or system dependant. Active Tags provides a generic and independant architecture, but Active Tags doesn't care whether active sheets are independant or not. There are no limitations of how an Active Tags engine may be used : as a standalone application or hosted by another application.

1.4 The engine

An engine that implements the Active Tags specifications is called an Extensible XML Processor; extensibility stands for the pluggability layer that allows to extend the basic features with other common or custom modules. The EXP specification describes how to manage such modules and how to change the standard behaviour of the engine described in this specification.

An engine that implements the Active Tags specifications must implement at least the following core modules :

• The EXP module (see the specification)
• The XCL module (see the specification)
• The ASL module (see the specification)
• The Active Datatypes module (see the specification)
• The Active Catalog module (see the specification)
• The internal fallback module described in this specification

The engine works with an XML document called the active sheet, which drives the processes to perform.

2 Overview with examples

Here are few examples commented to make easier understanding of the Active Tags technologies.

As only a few modules are defined by the core Active Tags specifications, those used in the examples above that are not part of the core Active Tags specifications may be purely imaginative.
Standard modules that are not part of the core Active Tags specifications provide similar services that those used in this examples, and may differ significantly because at the time of publishing they are not yet in a stable version. See the common modules list.

The following examples are intending to clarify the understanding of this specification.

2.1 Simple XML parsing and data extraction

The XML Control Language is one of the main module of the Active Tags technology. XCL is the base toolkit to perform simple actions. XCL provides instructions related to XML such as parsing, and familiar instructions used in imperative languages.

    <xcl:parse name="myXml" source="file:///path/to/myFile.xml"/>
    <xcl:set name="author" value="{ $myXml/document/author }"/>
    <!-- insert here what to do with an "author" node -->

    <xcl:parse source="file:///path/to/myFile.xml"/>
    <xcl:set value="{ document/author }"/>
    <!-- insert here what to do with an "author" node -->

The XML Control Language is a very useful module of Active Tags.

2.2 First complete active sheet

The preceding example was showing 2 tags alone ; this example shows them in a complete XML document. An XML document processed by an engine that implements the Active Tags specifications is called an active sheet.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
    <xcl:logic>
        <xcl:parse name="myXml" source="file:///path/to/myFile.xml"/>
        <xcl:set name="author" value="{ document/author }"/>
        <xcl:echo value="Author : { string( $author/text() ) }"/>
    </xcl:logic>
</xcl:active-sheet>

2.3 XSLT transformation

The XML Control Language provide various tags that allow to organize processes, control the flow process, and deal with XML datas.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
    <xcl:logic>
        <xcl:parse name="myXml" source="file:///path/to/myFile.xml"/>
        <xcl:parse-stylesheet name="myXslt" source="file:///path/to/myStylesheet.xsl"/>
        <xcl:transform output="file:///path/to/myFile.html" source="{ $myXml }"
 stylesheet="{ $myXslt }"/>
    </xcl:logic>
</xcl:active-sheet>

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
    <xcl:logic>
        <xcl:transform output="file:///path/to/myFile.html" source="file:///path/to/myFile.xml"
 stylesheet="file:///path/to/myStylesheet.xsl"/>
    </xcl:logic>
</xcl:active-sheet>

2.4 Batch processing

With XML technologies, it is often useful to publish an entire XML repository in HTML or PDF ; Active Tags allows to describe such a publishing process.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:io="http://www.inria.fr/xml/active-tags/io"
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
    <xcl:logic>
        <!-- the same stylesheet for all XML files -->
        <xcl:parse-stylesheet name="xslt" source="file:///path/to/myStylesheet.xsl"/>
        <io:file name="myRepository" uri="file:///path/to/my/xml/docs"/>
        <xcl:set name="myXMLFiles"
 value="{ $myRepository//*[@io:is-file][@io:extension='xml'] }"/>
        <xcl:for-each name="file" select="{ $myXMLFiles }">
            <xcl:parse name="xml" source="{ $file }"/>
            <xcl:transform output="{ substring-before( $file/@io:path, '.xml' ) }.html" source="{ $xml }"
 stylesheet="{ $xslt }"/>
        </xcl:for-each>
    </xcl:logic>
</xcl:active-sheet>

Modularization and cross operable objects are one of the most powerfull concepts of Active Tags.

2.5 Web embedding

Many applications are running on the Web ; an implementation of Active Tags that provides a Web module would be launched within a Web server.

<?xml version="1.0" encoding="iso-8859-1"?>

<web:service
    xmlns:io="http://www.inria.fr/xml/active-tags/io"
    xmlns:web="http://www.inria.fr/xml/active-tags/web"
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">

    <web:init>
        <xcl:parse-stylesheet name="htmlXslt" scope="shared" source="web:///WEB-INF/stylesheets/html.xsl"/>
        <xcl:parse-stylesheet name="pdfXslt" scope="shared" source="web:///WEB-INF/stylesheets/xslfo.xsl"/>
    </web:init>

    <web:mapping match="^/active-tags/(.*)\.(html|pdf)$">
        <io:file name="xmlFile" uri="web:///active-tags/{ $web:match/node()[1] }.xml"/>
        <xcl:if test="{ $web:match/node()[2]='pdf' }">
            <xcl:then>
                <xcl:attribute name="web:mime-type" referent="{ $web:response }" value="application/pdf"/>
                <xcl:transform name="pdfResult" source="{ $xmlFile }" stylesheet="{ $pdfXslt }"/>
                <serialize:to-pdf output="{ value( $web:response/@web:output ) }" source="{ $pdfResult }"
                    xmlns:serialize="http://www.inria.fr/xml/active-tags/serialize"/>
            </xcl:then>
            <xcl:else><!-- default is HTML -->
                <xcl:attribute name="web:mime-type" referent="{ $web:response }" value="text/html"/>
                <xcl:transform output="{ value( $web:response/@web:output ) }" source="{ $xmlFile }"
 stylesheet="{ $htmlXslt }">
                    <xcl:param name="page" value="{ value( $web:request/page ) }"
 xcl:if="{ $web:request/page }"/>
                </xcl:transform>
            </xcl:else>
        </xcl:if>
    </web:mapping>

</web:service>

2.6 Active Document : a dynamic XML document

A "normal" XML document may host snippet Active Tags actions to insert dynamic content in this XML document. Such a document is called an Active Document.

<?xml version="1.0" encoding="iso-8859-1"?>

<letter>
    <from>INRIA</from>
    <to>ACME</to>
    <content
        xmlns:sys="http://www.inria.fr/xml/active-tags/sys">
        <p>Please notice that you have until the {sys:add-date( $sys:date, 15)} to pay your invoice.</p>
    </content>
</letter>

If this example was executed by a processor, it would return a new XML document; however, it may be advantageous to design a new active sheet that generates a PDF document with the XML output produced, as shown below.

2.7 Driving Active Tags with Active Tags

Two active sheets may be used, one to drive the other. It is specifically useful to drive a set of XML documents that contains dynamic content expressed with Active Tags.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:exp="http://www.inria.fr/xml/active-tags/exp"
    xmlns:io="http://www.inria.fr/xml/active-tags/io"
    xmlns:serialize="http://www.inria.fr/xml/active-tags/serialize"
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
    <xcl:logic>
        <!-- the stylesheet to produce the XSLFO output (PDF) -->
        <xcl:parse-stylesheet name="pdfXslt" source="file:///path/to/pdfStylesheet.xsl"/>
        <!-- the letter (see the preceding example), that contains active tags -->
        <exp:unmarshal name="proc" source="file:///path/to/letter.xml"/>
        <exp:invoke name="{$proc}">
            <!-- what is kept from the invoked process -->
            <exp:exports>
                <exp:export name="xmlLetter" value="{current()}"/>
            </exp:exports>
        </exp:invoke>
        <!-- producing PDF output -->
        <xcl:transform name="pdfResult" source="{$xmlLetter}" stylesheet="{$pdfXslt}"/>
        <serialize:to-pdf name="pdfStream" source="{$pdfResult}"/>
        <!-- saving the PDF file -->
        <io:save content="{$pdfStream}" uri="file:///path/to/letter.pdf"/>
    </xcl:logic>
</xcl:active-sheet>

2.8 RDBMS mapping (SQL)

Tools that are mapping tables from an SQL query to XML structures often offers poorly means. RDBMS vendors usually provide non-standard mechanisms that allow to build low-flexible XML data structures which generally don't suit the user requirements ; XSLT is then used to reorganize such structures to fit the expected structure.

Active Tags offers a smart way to map directly any SQL query to the expected XML data structure.

<?xml version="1.0" encoding="iso-8859-1"?>

<order id="12345"
    xmlns:rdbms="http://www.inria.fr/xml/active-tags/rdbms">
    <rdbms:connect db="order-db" driver="..." host="..." name="order-db" passwd="..." user="..."/>
    <rdbms:select connexion="{$order-db}" name="orders"
 query="SELECT * FROM orders WHERE id={$this/order/@id}"/>
    <xcl:for-each select="{$orders}"
        xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
        <item part-number="{pn}" quantity="{qty}">
            <price currency="{currency}">{price}</price>
            <product>{product}</product>
        </item>
    </xcl:for-each>
</order>

Of course, the RDBMS module provides also a way to create, update, or delete table rows from informations taken from an XML source.

Other data sources (an LDAP repository) could be used similarly with an appropriate module.

2.9 SAX pipeline

Active Tags offers means to deal with XML specific processing methods (DOM or SAX) in the aim to enhance the global performances of an XML chain process. Usually, developpers connect the output of a step to the entry of the next step, building a SAX pipeline process.

To do so, processes that are dealing with XML datas simply have to indicate that the result of a step is of the SAX type.

    <web:mapping match="..." method="GET">
        <io:request connect="xmldb:provider://user:pwd@host:port" name="results" output-type="SAX"
 query="..." type="myQueryLanguage"/>
        <xcl:document name="allResults" type="SAX">
            <!--merge each result in a single document-->
            <results>
                { $results }
            </results>
        </xcl:document>
        <xcl:transform output="{ $web:response/@web:output }" source="{ $allResults }"
 stylesheet="results.xslt"/>
    </web:mapping>

2.10 Active Update (XUpdate enhancement)

XUpdate is an XML language based on XPath designed to describe the updates to apply to an XML document. XUpdate has been published as a working draft on september 14th 2000.

However, XUpdate doesn't define clearly alternative processing and not at all iterative processing ; it can't perform computation ; it doesn't care about commit or rollback.

Active Tags allows a more flexible usage of XUpdate ; its use is achieved in the XML Control Language ; it deals with the collaborative model of data exchange of Active Tags.

In Active Tags technologies, it is called Active Update.

<?xml version="1.0" encoding="iso-8859-1"?>

<xupdate:modifications version="1.0"
    xmlns:xupdate="http://www.xmldb.org/xupdate">
    <xupdate:insert-after select="/addresses/address[1]">
        <xcl:if test="{ not(following-sibling::address/@id=2) }"
            xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
            <xupdate:element name="address">
                <xupdate:attribute name="id">2</xupdate:attribute>
                <fullname>Philippe Poulard</fullname>
                <born day="10" month="06" year="1969"/>
                <town>Châteauneuf</town>
                <country>France</country>
            </xupdate:element>
        </xcl:if>
    </xupdate:insert-after>
</xupdate:modifications>

The XML Control Language implements Active Update, a similar but more complete and powerful mechanism to describe update operations (see the X-operation example). As XCL defines also an XUpdate-like language, the module shown in the example above is not listed in the module list (however, developpers could anyway provide an implementation of XUpdate for Active Tags).

2.11 Active Schema

The Active Schema Language is a very powerful schema language built upon Active Tags technologies. It allows to design schemata that cover almost all assertions expected on a document class, and provide means to use data type libraries and define custom data types.

Active Schema is slightly different than other schema technologies in the way that its content models may be computed dynamically ; Active Schema invents a new type of schema known as "active" because content models may adjust themselves to entries more accurately than other schema technologies.

<!ELEMENT Chapter (Title, ((Content, Chapter*) | Chapter+))>

<?xml version="1.0" encoding="iso-8859-1"?>

<asl:active-schema asl:version="1.0" target=""
    xmlns:asl="http://www.inria.fr/xml/active-schema">
    <asl:element name="Chapter">
        <asl:sequence>
            <asl:element ref-elem="Title"/>
            <asl:element min-occurs="0" ref-elem="Content">
                <asl:interim min-occurs="0" replace="yes">
                    <asl:sequence>
                        <asl:element max-occurs="unbounded" min-occurs="0" ref-elem="Chapter"/>
                    </asl:sequence>
                </asl:interim>
            </asl:element>
            <asl:element max-occurs="unbounded" ref-elem="Chapter"/>
        </asl:sequence>
    </asl:element>
    <!-- other definitions here... -->
</asl:active-schema>

2.12 Active Catalog

3 Engine behaviour

An active sheet is an XML document that can be processed by an engine that implements the Active Tags specifications. This section describes how implementors should design such engines. Each active sheet has its own instance of the engine with its own settings.

An engine that implements the Active Tags specifications works in two phases :

• the unmarshal phase
• the runtime phase

The unmarshal phase

The runtime phase

3.1 The unmarshal phase

This phase "transforms" XML tags in concrete actions that will be processed. In a certain way, tags are wrapping actions !

Once unmarshalled, an active sheet gives a processor instance. The active sheet is the serialized form of a concrete processor instance (this specification doesn't oblige an implementation to supply a mean to serialize a processor instance back to an XML document).

An action is a class designed to perform some process. An action may work alone or with subactions. Such dependency between actions is concretely represented in XML with nested tags. Actions may be :

• pre-compiled classes ready to use
• on-the-fly compiled classes

Unmarshalling delegation

The engine is responsible of tags unmarshalling ; that is to say that the engine chooses (or generates) the appropriate class corresponding to each tag encountered when reading the active sheet, and only the tags encountered. Each time a tag is encountered by the engine, a module request is launched with the namespace URI of the tag. If the module expected is known by the processor instance, it will deliver the concrete implementation of the action, otherwise, the internal fallback module will handle it. However, this behaviour may be tuned with EXP.

The class binding is defined within each module with a component (called a factory) responsible of the instanciation of classes that correspond to tags. However, once a tag has been unmarshalled, the corresponding class or its factory is responsible of unmarshalling its subtag :

• for a tag that doesn't work with subtags : the class won't do anything for this purpose
• for a tag that works with subtags :
  • the class may invoke the engine : the standard unmarshal process goes on.
  • the class may bypass the engine : the engine is no more responsible of class instanciation, but subtags may invoke themselves the engine that continues to unmarshal and so on.

Thus, once the engine delegates the unmarshalling process, some nested tags may not be encountered by the engine.

When a tag is delegated for unmarshalling, it is not necessary that other classes will be produced. There is no requirement for the number of classes to be the same of the number of elements. An engine could also generate a program code to be compiled and run on the fly.

Tags that are unmarshalling themselves subtags must take care of the EXP specification particularly with the directives that enable/disable prefixes. See internal tuning and external tuning.

Deferred unmarshalling

A tag may be designed to defer the unmarshalling of its subtag only when it is invoked at runtime.

Consequently, unmarshal errors may be raised at runtime.

Expressions

Each class bound to a tag is responsible of the tag's attributes interpretation. Attributes may contains values that are resolved at runtime, or litteral values. A value resolved at runtime must be an expression, that is to say a mixed-string of simple strings and XPath expressions surrounded by curly braces. Simple strings are strings that doesn't contain curly braces, or that escapes { and } with {{ and }}. When the expression doesn't contain curly braces, the string is used like a litteral value. When the expression contains a single XPath expression surrounded by curly braces, the expression may return an object at runtime. Any individual XPath expression may return any object. If an expression is composed with at least one simple string, the whole result is generally a string that contains the concateneted string values ; however, each part could also be considered separately if needed.

For example -as specified in the relevant specification- with the <xcl:parse> action :

<xcl:parse source="{$file}" ignore-comments="yes">

• the @source attribute is using an expression that will return the appropriate object,
• the @ignore-comments attribute is using a litteral value.

When an expression is found in the document content (that is to say in text nodes), it is taken in charge by the internal fallback module to produce an object at runtime.

A void expression ({}) or an expression that contains a single XPath expression filled with blanks ({ }) returns nothing.

XPath usage and object references

XPath expressions always appear in expressions.

When an expression is a single XPath expression surrounded by curly braces, it is often used to deliver an object reference other than XPath native object types. A tag that uses attributes with expressions should declare which types of object it is able to deal with.

Moreover, a typed object may be compared with another compatible typed object regardless the standard XPath comparison algorithm.

Notice that some non-XML objects (called cross-operable objects) may be traversed with an XPath expression made of several steps ; unusual XPath expressions can be used, and unusual XPath results can be obtained ; for example :

• {$users/bill/@birth-date} would return an attribute which name is "birth-date" and value is not necessarily a string.
• {value( $users/bill/@birth-date )} might return a date object.
• {string( $users/bill/@birth-date )} should return a string.
• {$users/bill/@phones/@home} is a valid expression.

In XSLT, XPath expressions that involve an attribute are used to retrieve their string value directly. In Active Tags, XPath expressions are keeping the entire object ; its value may be retrieved with the value() function. An attribute value is also retrievable with the standard XPath string() function.

3.1.1 Tag validity checking

A tag is used to accomplish a specific task; for this purpose, it may use attributes or subtags, that are constraint by usage rules.

These assertions may be expressed within the module that maps the tag with its class. However, an Active Schema may be advantageously used for this purpose because it can be used for validation only on elements that are unmarshalled.

Usually, a tag that works with subtags will invoke the standard unmarshal process. That will allow other tags from other modules to be nested. If a tag works exclusively with other tags from the same module, it may bypass the standard unmarshal process. However, this strategy shouldn't be choosen to ensure that right tags are used ; using a schema instead that constraints the tags of the module is a better strategy.

When a schema is used to check the validity, only tags that are unmarshalled by the engine are checked. It is the user responsability to validate subtags that are unmarshalled by delegation. This could be done directly by the implementation or by invoking the schema used by the module.

3.1.2 Classes factory

When unmarshalling, a component of the engine called a factory, is used to distribute instances of classes. Usually, theses classes are precompiled classes ; EXP is designed to define mappings between tags and classes of custom modules.

However, each module may define its own factory : instead of having a class for each tag, it may be convenient for the module designer to generate some code, compile it, and use it. For this purpose, an Active Tags implementation may use a master factory to distribute module factories responsible of class distribution.

3.1.3 Foreign attributes

In XML, unprefixed attributes are not bound to a namespace URI ; however they are said to "belong" to their host element, even if it is bounded to a namespace URI.

A foreign attribute is an XML attribute that is bound to a namespace URI (its name uses a prefix), usually different from those of its host element. A foreign attribute is active if it is defined by a module.

In Active Tags, foreign attributes are used as "directives" when unmarshalling, that cause a module request like tags. A foreign attribute may act on the unmarshalling phase or the runtime phase. When unmarshalling, an attribute that act on the unmarshalling phase is activated before its host element. An enabled module must supply an implementation of the task to perform, for example a configuration directive that acts on the processor instance.

Foreign attributes bound to a disabled module are ignored.

As attributes are unordered within an element, foreign attributes are applied in a specific order given by a priority indicator -an integer- that their owner module must define. High values are less prior than low values. -1 is reserved for internal usage and should be not used for custom modules. Zero is reserved for version settings (@foo:version). Module designers should use values greater than zero.

3.2 The runtime phase

Once an active sheet has been unmarshalled, a complete processor instance is ready to use. A data structure, called the data set, is used to store properties when performing the process. As several data set may be submited simultaneously, the built process must be a reentrant process. If the engine is hosted by an application, it is responsible of the data sets initialization and submission. If not specified, properties stored in a data set are not accessible by other threads.

The data model is described later in this specification.

At runtime, an action may work with special datas : the context that may be used by its subactions, and the current object that may be used by its following actions.

3.2.1 The current object

Many actions are producing a main object to put in the data set ; such actions often use the @name attribute. A quick and short usage of such object may be expected ; for this purpose, instead of storing such object, it may be convenient to refer to it as the current object. Thus, instead of naming the object produced, some actions may also work in an "anonymous mode", that cause the setting of the current object to those produced by the action.

The current object may also be stored with a name in the data set. When a current object is set, the preceding current object is lost if not stored in the data set with a name. However, actions that nests subactions may save the current object and restore it after their execution. Each action should be clearly documented if they allow this behaviour.

Any relative XPath expression starts from the current object.

Referring the current object

XPath expressions may be expressed indifferently from a specific object, or from the current one. If the current object is $foo, then {$foo/@bar} and {@bar} will return the same result.

The current object may also be retrieved with the current() function. If the current object is $bar and is the string "bar", then {$foo/@bar=$bar} and {$foo/@bar=current()} will return the same result.

In the examples above, the current object is also stored with a name in the data set, but this is not required. Thus, an object may be referred only as the current object.

3.2.2 The context

A context is a stackable structure that an action may initialize and consume after its subactions have been performed ; some subaction may feed the context with a data that will be consumed later. The context must preserve the order of the datas it receives.

Any action may be designed to :

• initialize and consume a context,
• feed a context,
• both.

The context may be retrieved with the context() function.

Usefulness

Many actions need to refer to a common data to achieve a specific action ; for example :

• An action that requires parameters defined at runtime may hold a context ; each parameter definition encountered when performing subactions are feeding this context ; at the end, the master action retrieves the set of parameters needed for its execution.

  A context parameter

  <xcl:transform name="htmlResult" source="{$xmlFile}" stylesheet="{$htmlXslt}"> <xcl:if test="{$web:request/page}"> <xcl:then> <xcl:param name="page" value="{$web:request/page}"/> </xcl:then> </xcl:if> </xcl:transform> This snippet code shows an action that performs an XSLT transformation. It is possible to pass parameters to the stylesheet because the relevant action has defined a context for it, that is fed with the <xcl:param> action. The XSLT transformation will be performed after the execution of its nested actions.

• Dynamic XML tree creation is also possible thanks to a context, as shown in the "dynamic XML document" example where fallback actions (each XML element not bound to a module, or XML text) will feed its parent element. The context initialized at startup will be used to set the value of the current object at the end of the process.

Special purpose context could also be defined by modules themselves. This is the case of the XCL module that defines a special context for Active Update operations.

Implementation details

A context is created on behalf of the action that needs it and its subactions that feeds it with datas. An action that push a new context must pop the context it has already pushed after its execution. The data set must define a stackable structure used as the context for actions that need one. Popping a context from the stack is the responsability of the action that creates it.

If the main logic procedure of an active sheet is invoked and the root element is not bound to an action, the context will be used to set the value of the current object.

An action that uses the datas of a context is free to accept or reject silently inappropriate datas. Usually, the datas that feed a context are of the same type, but inappropriate datas must never cause a crash.

An action could open successively several contexts. If so, this must be resolved when unmarshalling ; what causes the contexts separation must be clearly defined in the action.

Bubble messages

A bubble message is a special data used to feed the context on behalf of a specific target. When the action that opens the context is not targeted by the bubble message, it must feed the upper context with the bubble message.

According to the action that opens the last context, non bubble messages may be ignored or transmitted.

An action that deals with contexts must clearly define its behaviour regarding to non-bubble messages. It is recommended for such actions to transmit the datas not used to the upper level ; however, an action could act like a "context absorber" that blocks irrelevant datas.

3.3 Dynamic content models

Active Tags considers that an active tag that contains a set of declarations (declarative oriented subelements) will choose those to invoke (maybe none, maybe all) in an order that is not necessary sequential. On the contrary, imperative tags will be invoked sequentially.

Active Tags uses a powerfull mechanism that allow related declarations to be assembled at runtime rather than statically, which increases dramatically the expressive capacity of declarative-oriented grammars. The dynamic assembly of declarations is very usefull when the declarative model reaches its limits, for example when switching from one declaration to another needs more complex considerations of the context than those allowed.

The invokation phase

With declarative oriented actions, a third phase engine may be considered in addition to the unmarshal and the runtime phases. This phase may be considered as a subphase of the runtime phase.

Declarative actions are usually defined on behalf of a master component that use them in a specific way, not necessary sequentially like procedure-oriented actions. The activation of a declaration is totally arbitrary ; it depends on what its master component is intend for, and various invokation mechanisms may be designed. As such declarations can be mixed with procedural-oriented actions, it is necessary to describe how the engine can deal with them.

At runtime, a master component that uses declarative oriented actions will process them in two step :

• first, it will run its subactions sequencially as usual after openning a context. Each declarative action encountered will then feeds the context. Thus, usual procedure-oriented actions encountered will be performed ; for example, a declarative action may became conditional when enclosed in an alternative action. When feeding the context, the declarative action may use itself as the feeder-object, or another alternative object more suitable for the master component.
• secondly, the master component will use the declarations as needed, in the well-named invokation phase. The way of how a declaration is invoked is implementation dependant and may vary according to the master component targeted.

A master component that uses declarative oriented actions may be itself a declarative oriented action ; however, this mechanism is not limited to declarative oriented actions, and can behalf to any active tag that defines entirely or partially a dynamic content model.

When feeding the context, a declarative action may also run subactions if necessary ; its activation by the master component generally consist on invoking the underlying object with a specific method, not on running it ; but it could. Additionally, invoking a declarative action may also cause its subactions running. This two activation mechanisms are not necessary related.

Specifying static or dynamic content models

The definition of any active tag must indicate whether its content is static or if it can be dynamic. When the content of an active tag is specified as static, it may be assembled when unmarshalling, whereas when the content of an active tag is specified as dynamic, it must be assembled at runtime. A mixed content may be partially assembled when unmarshalling and partially assembled at runtime.

As a static action can be assembled when unmarshalling, its usage can be enforced in a schema ; on the contrary, allowing dynamic actions is much more loose regarding the constraints expressible in a schema ; at runtime, unexpected declarative actions should be reported as warnings and ignored by the host action.

A module must define the content of each of its active tags in terms of assembly, specifying for each of its subtags if it is static or dynamic. This consideration leads to definitions very different that schema technologies do.

<!ELEMENT xcl:if (xcl:then, xcl:else? )>

<!ELEMENT xcl:transform ANY>

    <xcl:transform source="file:///path/to/file.xml" stylesheet="file:///path/to/stylesheet.xsl">
        <xcl:loop test="{ not( $i ) or $i < 5 }">
            <xcl:param name="p{ $i }" value="{ $i }"/>
            <xcl:set name="i" value="{ $i + 1 }"/>
        </xcl:loop>
        <xcl:fallback id="xml:fatal-error">
            <xcl:document>
                <error>Parsing error</error>
            </xcl:document>
        </xcl:fallback>
    </xcl:transform>
                                

    <xcl:transform source="file:///path/to/file.xml" stylesheet="file:///path/to/stylesheet.xsl">
        <xcl:param name="p" value=""/>
        <xcl:param name="p1" value="1"/>
        <xcl:param name="p2" value="2"/>
        <xcl:param name="p3" value="3"/>
        <xcl:param name="p4" value="4"/>
        <xcl:fallback id="xml:fatal-error">
            <xcl:document>
                <error>Parsing error</error>
            </xcl:document>
        </xcl:fallback>
    </xcl:transform>
                                

3.4 Errors

Errors may occur :

• when unmarshalling,
• at runtime.

A fatal error denotes a non recoverable error that cause the processor instance in use stopping. Recoverable errors must not cause the processor instance in use stopping.

If the processor instance in use is running inside another processor instance, the fatal error must not corrupt the host processor.

When unmarshalling

When the unmarshalling process can't be performed without loosing actions, a fatal error occurs. This may happened :

• when a registered module can't be loaded,
• when a tag name is bound to a namespace URI that belongs to a module but is not known by the module,
• when the active sheet is not valid according to the schema used,
• when an element or an attribute is unexpected,
• when an attribute value is unexpected,
• etc

If the processor in fault is invoked from another processor (for example with EXP), the host processor must go on as explained in the next section.

Constraints expressed in a schema should be used to check the validity. When a constraint violation is encountered, an error or a fatal error occurs. The unmarshall process must go on to report other errors.

Some errors may be recovered when unmarshalling, for example by endorsing a default value when one is missing, or by providing a default action. This behaviour is module dependant, and must be described by the relevant specification.

At runtime

An error is identified thanks to a qualified name. Errors occurring at runtime are classified in 3 families :

• fatal error, that occurs when an action can't accomplish safely the task that it is intending for, and choose to interrupt the running process,
• error, that occurs when an action encounters some troubles, but that don't obstruct it to accomplish the task, sometimes with the help of additive processes,
• warning, that denotes that something unexpected occurs but the task is able to recover itself the problem.

In all this cases, a fallback process may be defined by the user, and invoked automatically when needed. After invoking a fallback process, the caller may abort or go on according to the fallback process definition.

Each action may define one or several fallback processes. The fallback processes of an action must be identified with a qualified name which denotes which kind of error it is able to process. A default fallback process that has no identifier may also be defined ; it will be used for all error not matched by the identified fallback processes.

A fallback process may define itself a fallback process.

Fallback processes are always static declarations.

Selecting the fallback process

• If the action responsible of the error defines fallback processes, those that have the same identifier than the error is selected if any.
• Otherwise, the fallback process is choosen from its parent action if any.
• Otherwise, its default fallback action is selected if any.
• Otherwise, the default fallback action of its parent is selected if any.
• Otherwise, if not specified by the action in fault, the default behaviour occurs.

To achieve this, XCL provides the <xcl:fallback> element.

4 Modularization

A module is a set of XML features grouped together. Active Tags allow users to define their own module. This chapter describes how the processor must invoke them when it handles an active sheet.

To use a module, the active sheet must use a namespace declaration. XML elements and attributes, and additionnaly XPath functions and qualified names of properties used in expressions or in attribute values, that use the same prefix as the namespace declaration in its scope, cause a module request.

As the namespace declarations of the XML source document are passive, a module is automatically loaded only on module request. Once loaded, a module can't be discarded. A module is expected when one of the following XML material cause a module request as indicated :

• XML elements and attributes are encountered when unmarshalling,
• XPath functions are encountered at runtime,
• predefined properties are encountered at runtime.

Unbound material

A processor instance must hold the list of modules it knows. The best way for this purpose is to supply a catalog, such as an Active Catalog. EXP provides a mechanism that allows to define additional modules. As a namespace declaration is not necessary related to a module, any XML material whose namespace is not related to a module is called an unbound material.

• Tags that are not bound to a module are not recognize as active tags, and felt on the responsibility of the internal fallback module.
• Attributes with prefixes that are not bound to a module are not recognize as active foreign attributes, attributes without prefixes are always inactive.
  • Attributes hosted by an active tag are ignored if they have been validated by a schema (but they are not ignored by the underlying action).
  • Prefixed attributes hosted by an active tag that are not active foreign attributes cause a fatal error.
  • Attributes hosted by an unbound element are taken in charge by the internal fallback module.
• XPath functions not bound to a module cause a fatal error.
• A qualified name not bound to a module used to retrieve a property is simply not found in the data set.

Bound material

Within an active sheet, tags, foreign attributes, XPath functions, and predefined properties are belonging to a module when their name is bound to its namespace URI. As unprefixed names of properties and XPath functions are not bound to a namespace URI, users must define a prefix if they want to use such XPath functions or predefined properties (like for foreign attributes that, by definitions, have a prefixed name). At runtime, a property bound to the namespace URI of a module won't cause an error if it is not a predefined property : it is processed like any other property.

For example, the namespace URI for the XML Control Language is http://www.inria.fr/xml/active-tags/xcl. Any tag, XPath function, or property name bound to this namespace URI is part of the XCL module.
The namespace URI http://www.inria.fr/xml/active-tags/sys allows to use a module that provides system interactions. With this module, environment variables are accessible through a predefined property.

The following example uses this two modules.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"
    xmlns:sys="http://www.inria.fr/xml/active-tags/sys">
    <xcl:logic>
        <xcl:parse name="myXml" source="{ $sys:env/myFile }"/>
        <!-- other stuff here -->
    </xcl:logic>
</xcl:active-sheet>

4.1 Module registration and loading

An engine that implements the Active Tags specifications must provide a lookup mechanism that allows modules to be registered and automatically loaded when necessary :

• when unmarshalling the active sheet, the first time that when the engine is responsible of unmarshalling, it encounters a tag for which a module exists,
• at runtime when a property or an XPath function belongs to a module that has not already been loaded when unmarshalling,

Once a module is loaded, it is capable on engine request to distribute class instances or to resolve property invokations.

An Active Tags engine must be implemented with at least the following core modules :

• The EXP module (see the specification)
• The XCL module (see the specification)
• The ASL module (see the specification)
• The Active Datatypes modules (see the specification)
• The Active Catalog module (see the specification)
• The internal fallback module described in this specification

It is encouraged that common extension modules are pre-registered to the Active Tags engine, so that many features will be available as they are used. See an example of modules accessible through a catalog.

Custom modules that are not pre-registered to the Active Tags engine may be specifically added with EXP (See the @use-catalog attribute of the <exp:processor> element). A module can be loaded only if it has been previously registered to the engine, or if the engine has means to retrieve the module.

Module lookup

Active Catalog is the default lookup mechanism for common extension modules and custom modules. A processor instance handles its catalog list that is processed each time a new module is expected. According to the Active Catalog specification, the catalog entry is the namespace URI of the module, and its selector is the qualified name exp:module bound to the namespace URI : http://www.inria.fr/xml/active-tags/exp.

Implementations are free to use another lookup mechanism for bootstrapping when loading any of the core modules.

4.2 The internal fallback module

The internal fallback module is used to produce an XML tree at runtime, like XSLT does. However, unlike XSLT, several XML trees may be produced and each are still updatable after creation.

Active tags and actions

Tags that are a feature of a module are active tags. An action is the program that accomplishes the feature.

A tag is "active" if it belongs to a module. Others cause a fallback action. An XML element bound to an action is an active tag.

Tags that are not bound to a namespace URI never belongs to a module.

Some tags and attributes have a role defined (essentially in a module), others haven't. Each tag or attribute that is active according to this specification must not be used to produce XML trees. Tags that are not unmarshalled to actions are used to produce XML trees.

At runtime, when such an element is encountered, its non blank text nodes will also feed the XML tree. The XML tree is produced in the order of the nodes encountered. Actions (like alternative or iterative processing) may influence the process flow and the XML tree production.

The internal fallback module is invoked when the nodes encountered in the active sheet are not taking in charge by a module. When unmarshalling :

• tags that belongs to a module cause a module request.
• tags that belongs to a module but that are intended to be handled by the fallback module instead of their own module (just because the namespace URIs are matching) must be disabled explicitely with EXP.
• non blank text nodes that are found in the document content are taking in charge by the internal fallback module.
• comments and processing instructions are ignored by the internal fallback module.

When the internal fallback module is invoked at runtime, it feeds the current context with the appropriate datas, that correspond to the nodes encountered :

• an element generates the creation of a child element that has the same name in the context ; its attributes are kept, but attribute values are interpreted as expressions. if the element has child nodes, the element created is stacked as the new context. An element that has opened a context appends to its content the XML material stored in the context, except the attributes and the namespace declarations which are set to the element.
• a text node that is an expression generates the creation of nodes after its evaluation :
  • if the result is a node or a node list or a collection of nodes, it is appended to the context as a child node ;
  • if the result is a collection of heterogeneous items, each is processed separately ;
  • otherwise it is appended as is, and converted to a text node after its string conversion if the component that opened the context was an element.
• a non blank text node that is not an expression causes the creation of a child text node with the same content.

An element created by the fallback module keeps its attributes, except those that are active foreign attributes (active foreign attributes are activated before the element), and XML namespaces declarations that are active modules (to check if a namespace declaration is related to a module, a module request without loading is launched).

Inherited namespaces are not set as attributes to an element ; only explicit namespace declarations are set.

<xcl:namespace> allow to define a namespace declaration on behalf of an element that wouldn't keep it if it was defined with the usual xmlns attribute declaration. Similarly, <xcl:attribute> allow to define additional attributes.

When the context is popped, the XML tree produced feeds the upper context. The XCL specification defines tags that can create or feed a context, for fine-grained XML tree production.

Whitespace handling

As specified above, blank text nodes are ignored by the internal fallback module. However, users that want some of them to be active just have to insert a void expression.

In the snippet code below, the text nodes inside the <foo:bar> element are preserved.

    .../...
    <foo:bar>{}
        <foo:oof/>{}
    </foo:bar>
    .../...

Text and CDATA sections are processed separately.

XCL also provides the <xcl:text> tag that allows to set the boundaries of non blank text nodes.

4.3 Extended XPath functions

Modules may provide a set of extended functions usable in XPath expressions. Extended functions may take in argument unusual objects, that is to say objects that are other than nodes, node-sets, numbers, booleans, and strings. Similarly, XPath functions may return any object.

An extended function is named with a qualified name ; a function name which is unprefixed is not bound to a namespace URI.

Implementors may found convenient to provide a function factory for each module.

4.4 Predefined properties

Predefined properties are properties that are already stored in the data set, or behave as if they were already in the data set, or are properties that are designed for a specific purpose on behalf of a module. Each module may define special properties for special purpose usage. Such properties must not be used for another usage that they are intended for. Such properties may contain static content, or dynamic content like $sys:random for which a different value will be computed each time it will be invoked.

Users should handle with care predefined properties : a module may restrict access to read, create, update, rename, or delete operations if necessary. Furthermore, a predefined property may be designed to store specific types of data. Attempting to perform a forbidden operation on a property must cause no trouble. Implementations may anticipate unexpected usage by logging such events or creating a predefined property that would contain a status, for example.

When needed, an invokation to a predefined property may cause side effects, that should be specified by the module specification.

The property resolver

The property resolver is the module component responsible of delivering the predefined property requested in an XPath expression. A property resolver may react :

1. on the qualified name of the property
2. on the namespace URI of the property

A module that defines a well known set of predefined properties should use the first resolution mode.

Implementations are free to provide a single property resolver for all predefined properties of the module, or one for each property, etc.

It is not required to serve a predefined property with a property resolver ; a predefined property may be an usual property that has a specific meaning on behalf of a module. Predefined properties that have a specific behaviour may have a property resolver, other won't.

5 Data model

Active Tags works with a structure called a data set used to store properties. A property consists of an object identified by a qualified name.

Active Tags allows to handle any categories of objects ; particularly :

• collection of named items : each item of the collection is bound with a unique key in its collection,
• collection of unnamed items : items are anonymous in the collection,
• cross-operable objects and XML objects,
• other objects.

Each item may be itself a collection or a simple object ; in a collection, items may be heterogeneous. Specific collections (created with an action of a module) could restrict read or update operations if necessary.

There are two ways to use properties :

• in the active sheet, with an XPath expression,
• by low-level programming : any snippet code of an action may use directly the data set to store or retrieve a property.

5.1 The data set

The data set is able to store any object (that could be a collection). Each object of the data set is named with a qualified name ; unprefixed names are not bound to a namespace URI. A property consists of the object stored and its qualified name.

The data set is also able to hold a special anonymous (unnamed) object called the current object. The data set is not responsible of setting or unsetting the current object.

As some active tags are used to produce a property within the data set, they may create the property at the end of the execution of their nested tags if they have any. An action designed to produce a property after its nested action execution may push a context to handle objects produced. Data set implementations must deal with contexts.

Several distinct data set may be used to process the same active sheet simultaneously. The active sheet may ends differently for each data set used for processing.

When an active sheet ends, the data set used may be processed by a host application (that may be an outer active sheet).

A property with a null value shouldn't be stored in the data set. If an action really needs to do so anyway, the underlying module specification must describe this. A property stored with a null value will behave like a not found property.

5.2 Property scope

An action that stores properties within the data set must define a scope for each, that can be one of the following :

• shared : a property is shared when the Active Tags engine is running in a mutli-threading enviroment, like a Web server. Properties that are shared are shared on the same processor instance, that is to say are accessible by any thread that runs the same active sheet. Notice that users must be careful with synchronization for datas that require concurrent access management, according to whether the shared object support synchronization or not.
• global : a global property is accessible in any logic procedure of the active sheet for the current thread.
• local : a local property is accessible in only the current logic procedure. When a call to another logic procedure is performed, it is possible to pass parameters and catch returned values.

• overlay : this scope isn't a defined scope; it applies only on predefined properties. Each module defines for each of its predefined property a specific scope, that takes precedence on the standard scopes listed above. It is not recommended to define a property that uses the same name of a predefined property. Each module specification explains how to use its predefined properties. Furthermore, like accessibility, creation, update and deletion is ruled by the module.

If not specified, an action that creates a property will use by default the local scope. If an action creates several properties, each may be stored with a specific scope.

Invoking

When a property is invoked (with $foo or $bar:foo in XPath expressions), it is looked up first in the predefined property set of the module to which the property is bound, if any. If it is not the case, or if it is not found, it is looked up in the local property set, then in the global property set, and finally in the shared property set.

When a property invoked is not stored in the data set, a null value is returned. Notice that null is casting to false by the XPath engine when performing boolean operations. It is useful for testing if a property exists or not, like this :

    <xcl:if test="{ not( $foo ) }">
        <xcl:then>...</xcl:then>
    </xcl:if>

At runtime, properties with a qualified name bound to a module that are not handled by a property resolver are extracted from the data set, if they exist.

Shadowing

When a property is stored in the data set, it is stored with a specific scope. As scopes are following a hierarchy, a property may shadowed another property that has the same name but a lower scope.

A property defined with a lower scope than another one with the same name can't be accessible by property invokation in an XPath expression, except if a tag was specifically designed for this purpose. An implementation of an action could also perform direct access to the data set with a given scope if needed.

5.3 Cross operable objects

Objects usually expose their internal state with public members. The cross-navigation allows internal variables of so-called X-operable objects (cross-operable objects) to be accessed with an XPath expression.

X-operable objects are XML compliant thanks to a component called an X-operator. An X-operator is suitable for objects that :

• are structured in a hierarchy
• have a set of properties
• have a content of homogeneous objects

The list above is just a guideline for designers ; at their convenience, any object may be exposed or not as a cross-operable objects.

An X-operator is a sort of visitor of the object it represents that is able to deliver a data when invoked with an XPath expression. An X-operator is also able to perform update operations when they are allowed. An X-operator is selected at runtime by the engine according to the type of object encountered.

For example, assume that a class Book have a title, a price, and a content ; it would be convenient to retrieve them with $theBook/title, $theBook/price, and $theBook/content, if $theBook was an instance of this class.

Like with collections, XPath expressions may be expanded to cross such objects : $coll/*[title='Hamlet']/content/document/author ; children of cross operable objects are not necessary XML nodes, they can be any object, cross-operable or not ; similarly, the value of cross operable objects attributes are not necessarily strings.

It is recommended that most objects stored in a data set are X-operable objects. To increase flexibility, modules designers are encouraged to expose the objects intended to be stored in a data set with an X-operable interface.

X-operable objects other than XML objects are not obliged to support all XPath features. An X-operable object is just used to provide accessibility to one or several of its internal variables with an XPath expression. When necessary, they may be updated with X-operations.

An X-operable object may be slightly different as usual XML objects : for example, an attribute may host another X-operable object that may have itself its attributes. An XPath expression like the following may be legal : @foo/@bar.

5.4 Active Update

X-operable objects may be updatable with a set of basic operations, that can be applied on the object with various means, according to its intrinsic characteristics, the axis it supports, and specifically its eventuals attributes. Each specific X-operable object is free to support or not the primitive operations listed below.

Active Update provides a standard way to update an object when a primitive operation is relevant for one of its characteristic ; in a module, specific actions may be designed to act directly on an object characteristic that is not accessible with Active Update. For example, a directory of a file system may be exposed as a cross-operable object ; its child axis provides the list of the files it contains, but is not updatable, but an action might be designed to create a new file in this directory.

Operating primitive operations

Various actions can be considered to perform any of the primitive operations.

XCL provides a full implementation of Active Update that maps precisely actions to these primitive operations.

Dependancies

Some operations denotes that the object referred (called the referent) is part of a collection for which order may be important, or not ; for example, XML elements are such objects. When specified, the referent may be an integer that denotes the position of the object referred within the collection it belongs. The first item in a collection is at the position 1.

Some objects may be hierarchically linked to another object that it depends, called its parent. It is itself one of its children. Some operations on such objects may require to specify explicitely the parent of the referent when it is involved, others don't need to.

When specified, an operand is needed to perform a specific operation.

If the referent computed at runtime gives nothing, the operation fails without trying to resolve other datas (parent, operand, and inner actions).

Deferred operations

When used alone, an operation is applied when encountered at runtime.

However, a set of operations may be grouped to be committed or rollback on request. When this feature is used, the operations encountered are deferred operations.

For this purpose, XCL provides the <xcl:commit> and <xcl:rollback> actions. The <xcl:operations> action is used to define the boundaries of a set of nested operations.

A deferred operation must resolve its referent, parent and operand as soon as it is encountered. When applied, it must not resolve them again.

This facility has been introduced to ease the usage of XUpdate-like operations on XML objects when incompatible updates are encountered : for example, if the first element of a node set must be removed and the second one must be updated, the expected result won't be obtained because once the first element will be removed, the second will become the first and the third the second ; this is those that will be updated.

A set of deferred operations act like if the XML document were frozen during the updates operations that are really applied later.

If not specified, a set of deferred operations is applied automatically at the end of its execution.

Example

<xcl:operations deferred="yes">
    <xcl:remove referent="/addresses/address[1]"/>
    <xcl:insert-after referent="/addresses/address[2]">
        <xcl:if test="{ not(following-sibling::address/@id=3) }">
            <address id="3">
                <fullname>Philippe Poulard</fullname>
                <born day="10" month="06" year="1969"/>
                <town>Châteauneuf</town>
                <country>France</country>
            </address>
        </xcl:if>
    </xcl:insert-after>
</xcl:operations>

Primitive operations

Each cross-operable object must define a set of characteristics for which primitive actions (read, write, update, delete, rename) must be clearly allowed, as explained in the next chapter.

When a read operation is involved, the type of object returned and eventually its possible values must be specified.

The delete operation is significant regarding to the parent object it depends on.

The write and update operations are similar but differ slightly:

• the write operation zaps an eventual old value
• the update operation is used for localized updates of collections, such as those provided by (but not limited to) <xcl:insert-before>, <xcl:insert-after>, <xcl:replace>
• when an update operation is allowed, a write operation is implied when omitted
• a write operation doesn't necessary implies an update operation

Notice that the actions provided in XCL are designed to handle single objects as well as collections such as adt:list of objects; in this case, the actions are doing the right thing by processing each object.

The update operation is exposed in a cross-operable object as a process on a single object.

5.5 Cross-operable object template

This chapter introduces a template definition for any cross-operable object. The module specifications should use such a template.

In the following template, operations can be processed with many means which can be introduced by a title just above:

• operations on the object itself (these operations are not introduced by a title) : they act on the object itself (rename, delete). Sometimes, an operation needs a parent object to be effective ; for example, a deletion may be performed depending on the parent object ; if the parent axis is provided, it is not necessary to provide it explicitely when performing a delete operation.
• function() : the functions involved are standard XPath functions and additional Active Tags functions for which the result depend on the object on which the function is applied. According to the evaluation context, some functions may behave as specified in the relevant specification ; for example, let's consider that the position() function is defined for a cross-operable object ; if it is part of a adt:list, the value returned will be its position within the list, not the value specified in its definition.
• axis:: : the XPath axis supported by this object ; axis that are deduced from basic axis are implicitely supported. For example, if the parent:: axis is supported, then the ancestor:: axis is also supported. An unsupported axis must never cause an error : when crossing an axis, as heterogeneous objects may be encountered, an object that can't provide a next item in the axis considered, or that doesn't support this axis stands for the last object of the axis.
• @attribute : a specific attribute in the attribute axis ; unlike XML attributes, any type may be considered.

When a type and eventually a value is specified, it is a return value if a read operation is concerned, an argument if a function is involved, or an operand otherwise.

Contextual functions

Deducible axis

Two irregular axis are added to the standard XPath axis : next:: and previous::. They must not be used in XPath expressions. They only appear in cross-operable object definitions to denote that objects are chained together. They are conceptually respectively equivalent to the first following-sibling:: item and the first preceding-sibling:: item.

When not specified, the axis may be deduced from other axis that are specified, as shown below. If not specified, the self:: axis returns the cross-operable object itself.

• ancestor:: : deduced from parent::
• ancestor-or-self:: : deduced from ancestor:: and self::
• descendent:: : deduced from child::
• descendent-or-self:: : deduced from descendent::
• following-sibling:: : deduced from next::
• preceding-sibling:: : deduced from previous::
• following:: : deduced from following-sibling:: and descendent-or-self::
• preceding:: : deduced from preceding-sibling::, parent::, child::, and self::

Template

	Allows a read operation.
	Allows a write operation.
	Allows a rename operation.
	Allows an update operation.
	Allows a delete operation.

The acme prefix is bound to the http://www.acme.org/boat namespace URI.

acme:x-boat type

Represents an ACME's boat object.

Operation			read | write | rename | update | delete
	Type	Value	Comment
	xs:QName		The new name of the boat.
type()
	xs:QName	acme:x-boat	This type
name()
	xs:QName		The name of the boat.
string()
	xs:string		The string value of the boat is its local name.
parent::
	acme:shipowner		The shipowner of this boat.
child::
	adt:list of acme:crew		The crew of this boat.
	acme:crew		A crew of this boat. As this type accept update operations on its children, an insert-before action could be considered ; in this case, the referent of such operation will be an acme:crew, the parent an acme:boat, and the operand a single acme:crew or a list of an acme:crew. Moreover, an insert-before action would really process an append action if ordering is not relevant for an acme:crew, that is to say if its position() function is not defined.
next::
	acme:x-boat		The next boat. This irregular axis is used by other axis such as following-sibling:: if it is not explicitely defined for this object.
previous::
	acme:x-boat		The previous boat.
attribute::
	adt:map of xml:attribute		A fixed set of attributes (see below).
@captain-age
	xs:nonNegativeInteger		The age of the captain.
	xs:nonNegativeInteger		Set the new age of the captain.
@can-sink
Indicates whether or not this boat can sink.
	xs:boolean	true	This boat can sink.
		false	This boat can't sink.
	xs:boolean	true	Mark this boat so that it can sink.
		false	Mark this boat so that it can't sink.
@has-sunk
Indicates whether or not this boat sunk.
	xs:boolean	true	This boat has sunk.
		false	This boat hasn't sunk yet.

<?xml version="1.0" encoding="iso-8859-1"?>

<xcl:active-sheet
    xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl"
    xmlns:acme="http://www.acme.org/boat">
    <xcl:logic>
        <acme:define-boat boat-name="titanic" has-sunk="true" name="acme:boat"/>
        <xcl:append referent="{$acme:boat}">
            <xcl:attribute name="can-sink" value="{false()}"/>
        </xcl:append>
        <xcl:echo value="{name($acme:boat)} can sink ? {$acme:boat/@can-sink}"/>
        <xcl:echo value="{name($acme:boat)} has sunk ? {$acme:boat/@has-sunk}"/>
    </xcl:logic>
</xcl:active-sheet>

6 The active sheet

The active sheet is the XML document that will be unmarshalled and executed by the processor.

As explained below, an active sheet may be purely declarative, procedural, or hybrid. Furthermore, an active sheet may also be a dynamic XML document, standalone or not, called an Active Document.

6.1 Typology

There are four types of active sheets, that is determined essentially by the root element of the XML document : if it is bound to a module, it is of the type 1 or type 2, otherwise (fallback) it is of the type 3 or type 4.

The following concepts are defined only in the scope of this specification in the aim of clarifying its understanding.

Declarative oriented processes (type 1)

XML documents that drives programs without procedural sentences are declarative oriented processes. With such XML documents, an engine will understand the logic given by the elements, but the control won't be provided in the XML document.

Some XML configuration files are in this category ; for example, an XML catalog describes how to retrieve XML documents in a declarative way. In a certain manner, schema languages such as W3C XML Schema and Relax NG are also describing constraints in a declarative way ; the web deployment descriptor of the J2EE architecture is also in this category ; however, none of them is an Active Tags application. On the other hand, Active Catalog and Active Schema both Active Tags applications and declarative oriented processes.

Procedural oriented processes (type 2)

In most languages, the source code begins with a declarative sentence that usually names the program, followed by the list of libraries used. Although these sentences are declarative -like the declaration of the procedures, functions, or classes- the essential source code consist of a list of instructions that will be executed sequentially.

When an active sheet follows these construction, it defines a procedural oriented process.

Dynamic Active Documents (type 3)

Such documents are designed to embed here and there some snippet Active Tags code that will be replaced by computed datas at runtime. Users usually get back the result document to perform some other processes. To do so, they may design another outer active sheet that will invoke the former (as shown in the examples "dynamic XML document" and "invoking" ).

Active Documents are close to "web server pages" technologies such as ASP, JSP, or PHP ; like these technologies, an Active Document could also be processed inside a Web server ; unlike these technologies, an Active Document may be processed independently of a Web server.

Standalone Active Documents (type 4)

These documents are a variant of the type 3. However, they are not invoked from an outer active sheet, but embeds directly within them an additional logic procedure used at startup, as shown in the example below.

<?xml version="1.0" encoding="iso-8859-1"?>

<letter>
    <from>INRIA</from>
    <to>ACME</to>
    <content
        xmlns:sys="http://www.inria.fr/xml/active-tags/sys">
        <p>Please notice that you have until the {sys:add-date( $sys:date, 15)} to pay your invoice.</p>
    </content>
    <xcl:logic
        xmlns:io="http://www.inria.fr/xml/active-tags/io"
        xmlns:serialize="http://www.inria.fr/xml/active-tags/serialize"
        xmlns:xcl="http://www.inria.fr/xml/active-tags/xcl">
        <!-- the stylesheet to produce the XSLFO output (PDF) -->
        <xcl:parse-stylesheet name="pdfXslt" source="file:///path/to/pdfStylesheet.xsl"/>
        <!-- the letter (see the preceding example), that contains active tags -->
        <xcl:call logic="#main">
            <!-- what is kept of the invoked process -->
            <xcl:keep name="xmlLetter" value="{current()}"/>
        </xcl:call>
        <!-- producing PDF output -->
        <xcl:transform name="pdfResult" source="{$xmlLetter}" stylesheet="{$pdfXslt}"/>
        <serialize:to-pdf name="pdfStream" source="{$pdfResult}"/>
        <!-- saving the PDF file -->
        <io:save content="{$pdfStream}" uri="file:///path/to/letter.pdf"/>
    </xcl:logic>
</letter>

6.2 The root element

In an active sheet document, the root element is non significative, except for modules that require explicitly a specific element. Thus, any root element is generally allowed.

When the root element is not bound to a module, such an element and its descendent is part of the main process flow, as describe in the next section.

When the root element is an active tag, and the main process flow is invoked, the underlying action will be performed. Otherwise, it is used for fallback and will produce an XML tree. For the root element, the XML tree will be bound to a context automatically openned. At the end of the XML tree production, it will be stored in the current property.

At the end of the runtime phase, the current property that contains the XML tree migth be retrieved by the invoker process if any, or serialized to the standard output for a standalone processor (for example).

6.3 The logic procedures

A logic procedure is a process unit defined by a specific tag (<xcl:logic> in XCL, <web:mapping> in the Web module, etc) that sets the limites of the scope of the local properties of the data set. A logic procedure may be called with various specific actions or behaviours, according to the modules used. When called, the nested actions are dealing with a new empty set of local properties. If necessary, the caller could send parameters to the logic procedure called, that would be set in the new empty set of local properties. This can be done thanks to other nested tags, directly by the tag implementation, or both.

On the other hand, global and shared properties are still accessibles by the logic procedure called.

After invokation, the local properties set by a logic procedure are lost unless they are explicitely imported in the caller logic procedure. This could be done thanks to other nested tags, directly by the tag implementation, or both. In this cases, the module that owns the caller tag must describe how to keep return properties.

A caller tag may be designed to replace, stack, or initialize the current context and the current object.

A logic procedure is not necessarily obliged to contain procedural oriented processes, as described in the chapter about "typology".

The default logic procedure

A logic procedure is usually identified with a qualified name, but with certain modules, a unique unnamed logic procedure may also be defined ; such a logic procedure is called the default logic procedure ; it may be referenced with #default. As several modules could design a tag that defines the default logic procedure, each time such a tag is encountered when unmarshalling redefines (zaps) the default logic procedure.

The default logic procedure can be defined only when a tag is designed to define a named logic procedure and when the name is missing if it is allowed. Other logic procedures would be invoked with a mechanism that not involves a name, and can't stand as the default logic procedure.

The main logic procedure

Furthermore, an active sheet may also be itself directly an entire logic procedure, such as shown in "dynamic XML document" and "rdbms" examples ; such a logic procedure is called the main logic procedure ; it may be referenced with #main. Any active sheet has its main logic procedure, which corresponds to the root element.

The procedures available

The processor must maintain the list of the logic procedures available. When a tag is designed to invoke a logic procedure by its qualified name, #main and #default could be used instead unless otherwise specified.

6.4 The startup

At runtime, the processor will choose :

1. the logic procedure that has the same qualified name of those specified if it is the case ;
2. otherwise, the #default logic procedure if it exists ;
3. otherwise, the #main logic procedure.

Notice in step 1 that #default or #main may be also explicitely specified.

Applications that embeds the processor and standalone processors may behave differently :

• when the runtime phase starts, a standalone processor will behave as indicated above ;
• applications that embeds the processor may be designed to invoke other predefined logic procedures. Such applications could also be designed to launch several threads ; each thread has its own data set. For example, a Web application will invoke the <web:init> logic procedure when the Web server starts, and will invoke the <web:mapping> logic procedure each time the server will process an HTTP request.

Additionnaly, the EXP specification defines its own invokation rules.

7 Core reference

7.1 Active Tags predefined properties

The following general properties are not bound to a namespace, thus usable directly. They don't belong to a module. It is the user responsibility to not use these properties for another purpose that they were intending for.

$this

Property type: xml:document

$this is the XML tree of the active sheet.

$this should be used only for reading XML datas. Attempting to update this XML tree may cause irremediable dommage to the underlying processor instance. However, unreachable parts of the active sheet may be updated without causing a crash. An unreachable part of the active sheet corresponds to a tree fragment that can't be performed in any way.

7.2 Extended XPath functions

The following functions are added to the standard set of XPath functions.

Notice that these functions are not bound to a namespace URI (they don't belong to a module), thus they are an extension of the usual XPath functions. As they are not belonging to a module, these functions are available without needing to declare a specific namespace URI in an active sheet.

current()

Return: any

This function returns the current object, as described previously in this specification.

context()

Return: adt:list of any

This function returns the context, as described previously in this specification.

ends-with()

Return: xs:boolean

This function is the same as the standard XPath function starts-with(), except that it tests if a string ends with an other one.

Arguments and return values
1	xs:string		The base string.
2	xs:string		The string to test if it is at the end of the base string.
Return	xs:boolean	true	If the base string ends with the string to test
		false	Otherwise.

The arguments are the same as the starts-with() function.

qname()

Return: xs:QName

This function computes a qualified name.

Arguments
1	xs:string		The qualified name ; the namespace URI is resolved with the set of namespace declarations known by the engine ; if an NCName is given, the qualified name built won't have a namespace URI.
Arguments
1	xml:element		The QName of the element.
Arguments
1	xml:attribute		The QName of the attribute.
Arguments
1	adt:item		The QName of the item.
Arguments
1	xs:string		The namespace URI.
2	xs:string		The qualified name.
Arguments
1	xs:string		The namespace URI.
2	xs:string		The prefix.
3	xs:string		The local name.

This function returns a qualified name object.

A QName object is not necessary build with valid XML names. If so, an object can be safely named in XPath expressions ; otherwise, an XPath expression that requires to test the name of the object must use * and test the name or local name with a predicate.

This facility has been introduced for objects that have to deal with QNames without the restrictions inherent to XML names.

To check if a QName is built with valid characters, just try to build an element, for example, with it. If the element can't be created, then the QName object contains invalid characters.

value()

Return: any

This function returns the value of a named item or other object that has a name and a value.

Arguments
1	xml:attribute		The attribute value.
Arguments
1	adt:item		The item value.
Arguments
1	other		The value of the object if it has a name and a value, or the object itself.

type()

Return: xs:QName

This function returns the type name of an object. An anonymous type has no name :-)

The name of a marker type is implementation dependant, and may return a class-name wrapped in a QName.

Arguments
1	any		An object.

8 Core modules

This chapter introduces the main modules of the Active Tags technology and how they are coupled. Readers should refer to their respective specification for detailed informations.

The need of revisiting core XML technologies such as schemata (Active Schema) and catalogs (Active Catalog) has been motivated by the will to design a unified set of XML technologies made for cooperation.

Focusing on problematic

Active Tags has been divided on several specifications, each focusing on a well-defined problematic.

This approach allow implementations of each specification decoupled from one another ; anyway, they may cooperate to accomplish a specific complex task.

For example, Active Schema doesn't define schema inclusion/import mechanisms, because Active Catalog provide means to retrieve resources. Active Schema may use custom XPath functions, but doesn't provide a mean to define them, because EXP does.

Similarly, as shown in the picture below, different module may cooperate to achieve a given task. In the aim of validating and binding an active tag to its implementation, several modules should be involved :

• the EXP module to bind the class to the active tag,
• the Active Schema module to validate the attributes and the content of the active tag,
• the Active Catalog module to supply the 2 resources above.

Moreover, the EXP module has also itself an EXP module that binds an implementation to its tags, and a schema that expresses constraints on this tags ; both resources are supplied with a catalog. Similarly, an Active Schema and an Active Catalog are also validated by a schema, bound to classes described by the EXP module, and supplied by a catalog.

Module cooperation while resolving an active tag

The Active Tags specifications provide basic tools that users may link together at their convenience.

8.1 EXP

EXP is part of the core modules of Active Tags. It provides various tags and attributes to tune the processing and build customizable processor instances.

EXP may be used to define the bindings between tags, extended XPath functions, predefined properties, foreign attributes, and their concrete implementation. Additionally, EXP offers a macro mechanism that allows to define macro tags and macro functions.

Finally, EXP may also be used for bootstrapping and offers logging facilities.

8.2 XCL

The XML Control Language is part of the core modules of Active Tags. It provides various tags for general purpose processing and XML processing, like :

• usual control structure actions, such as alternative or iterative actions, and logic procedure declaration and invokation ;
• XML oriented actions, such as XML parsing and XSLT transforming ; these actions deal with entity and URI resolving, passing parameters, error handling and many other options used to tune XML processes ;
• Active Update related actions, that fill the blanks in the original concepts drawn up in the XUpdate specification, and provides means to update non XML-objects with the same instruction set.

8.3 ASL

ASL is a powerful schema technology that allows to express more assertions expected on a document class than other schema technologies.

ASL is able to define semantic and polymorphic datatypes, can define content model dynamically, and can compute occurrence boundaries at runtime, which increases dramatically the expressiveness of the schema.

The Active Schema Language focuses on schemata problematic, which make it very light : the tag set used for designing schema instances is composed of only 20 tags. ASL can cooperate with other Active Tags modules either in the aim of enhancing its possibilities, as well as for managing and assembling several schema instances.

ASL instances can be used as schema patches to legacy schemata such as DTD, Relax NG or W3C XML Schema.

8.4 Active Catalog

Active Catalog revisits the XML catalog technology to respond to many Active Tags requirements :

• an Active Catalog can both translate URIs or supply resources,
• an Active Catalog can supply several resources from the same URI key,
• an Active Catalog offers caching facilities and means to build object instances and rebuild them if they have been discarded.

8.5 Active Datatype

Active Datatype is a specification that groups several requirements related to datatypes :

• it describes how objects are exposing their types in Active Tags,
• it makes a bridge between existing W3C datatypes and Active Tags,
• it borrows to XML some names to define common XML datatypes such as xml:element and xml:attribute,
• and define a set of additional datatypes.

Appendix

A Common Active Tags modules

This list is not exhaustive; it is a list of common modules usable by an engine that implements the Active Tags specifications that implementors may use. Additional modules are welcome.

B Lists

B.1 Examples list

• Simple example
• An active sheet
• Transformation to HTML with XSLT
• Batch example
• Web embedding example
• Example of a dynamic XML document
• Invokation example
• RDBMS mapping example
• 3-tiers Web application with a SAX pipeline
• XUpdate example
• Active Schema
• A context parameter
• Impact of dynamicity on schemata
• Module requests
• Example of X-operations
• Using a cross-operable object
• A standalone dynamic XML document

B.2 Figures list

• The unmarshal phase
• The runtime phase
• Module cooperation while resolving an active tag

C Active Tags and other technologies and tools

XSLT

XSLT allows to perform single XML transformations ; Active Tags allows to drive complete publishing processes with several entries from different sources and produce complex publications. Altough the fallback module is also designed to produce XML outputs like XSLT, Active Tags also allows to update existing XML trees unlike XSLT.

Ant

Ant is a tool designed for batch processes (make files) related to Java technologies. Active Tags is a specification, it is not particularly related to Java technologies. Active Tags allows more flexibility in describing processes. Ant refers to properties with a proprietary addressing mode, not compatible with XPath. As Active Tags relies on an XPath engine, properties addressing benefits of all the computation power of XPath.

JSP / JSTL

These server side technologies are usable exclusively in a Web application with the Java technologies. Active Tags may be used in a various environments and potentially many languages, both server and client side. A dynamic XML document -as described in this specification- used in a Web server, is very close to document-centric programming.

XQuery

XQuery is certainly the technology the closest to Active Tags, altough XQuery doesn't rely on pure XML (in the sense that the XQuery instructions are not expressed with tags).

However, Active Tags allows to deal with other data sources such as RDBMS, and many non-XML data sources and objects may be accessed with XPath. Furthermore, pure declarative sentences may be mixed with oriented procedural processes with Active Tags, unlike XQuery.

XML Data Binding

The usual XML data binding techniques and tools (JAXB, Castor...) are not designed to express processes cooperation. Active Tags defines a generic way to mix declarative-oriented processes and procedural-centric processes. Active Tags defines a tiny and smart common sharable data model.

XUpdate

The XML Control Language -that is part of the Active Tags specifications- provides a subset of tags that covers the XUpdate working draft specification much more efficiently. The XML Control Language achieve this specification by removing ambiguities and bringing the Active Tags facilities.

Active Tags proximity

People that are well aware of one or more of this technologies (and others) should recognize them in Active Tags, because Active Tags is very close to all of these concerns. That makes Active Tags easy to understand and easy to learn.

D Known implementations

This list is not exhaustive. Additional implementations are welcome.

• RefleX, a full Java implementation with many modules (ASL, RDBMS, I/O, Web, etc).