|
|
Author: V.G. FREMAUX Version: 1.0 / Janvier 2002 This project issued from the settlment of the Applied Research Laboratory of the International Graduate School for Computing Sciences in Cergy (France). We had till now sufficient success with the initial implementation of the DIML processor to keep on specifying and extending the process. We do not still now, when writing this specification, the possible outcome for this document, wether it may be published one day, submitted to the W3C or any other way to have it discussed in a larger community. We tried however to write it in the closest respect of the actual requirements of the Internet Community.
The present document defines a strategy to have DIML pages fed with data extracted form standardized XML documents. The general encoding of an electronic document that uses dynamic content generation, however it is published, can be divided in four syntaxical subensembles. The first layer represents the procedural process by which resources and content elements are fetched and prepared in order to produce the document. The second layer is the encoding syntaxes for the presenting options that has been actually efficiently condensed with the use of stylesheets based either on cascading attributes (CSS) or pipe-lined transformers (XSL). Then comes the layout or the physical organization of the distinct parts of the information, that is in another way the document macro-structure. This syntaxic encoding will define the location, the occupied space, and will imply a semantical hierarchy or categorization of content sequences (in-line sequences). The last one is the encoding of the proper content, generally using some set of symbols (character set). DIML optimizes the document structure management allowing a huge reusability of code sequences that encodes the content and thus allows an efficient separation between layout and process. Conversely, the DIML does not include any strong mechanism to dissociate semantic content and structure/layout. Someone who were exclusively responsible of the "message" writing cannot edit and update the information in a readable and natural way. The real information is usually mixed and merged with layout and structural HTML code. We though when we started this study that DIML could be a "soft" alternative to XML. We must express now our confidence in that XML combination with DIML when dealing with highly automated document process has a great interest. XML allows some form of extra-clean expression of the basic semantic whithout any influence of layout or presentation. This elementary construct may be sufficient to provide qualified parts of litterals involved in a content, having unique identification capability, and thus allowing them to be extracted and processed as unity elements. The minimalism of the basic XML, when being processed by the DIML processor, can be the native form of a huge amount of litteral content in highly automatized document generation applications.
3. The Data Injection Gateway3.1 Calling A XML DocumentThe XML Data Injection Gateway allows translating the elements of the XML file for use by the ESSI processor. After an XML document has been called, its XML elements (or some defined part of these elements) are translated as DIML variables. These variables thus can be used as any other DIML variable may it be obtained compiling a template, or invoking scripts or retrieving standard variables. The gateway will be mainly used for injecting litteral static contents that is part of some dynamic generated contents. This interface should be usefull to get higher management control on informational texts, user support indications, multi-language adaptation, or dynamic process configuration and will allow application logic to be developped and tested whil final writings are executed elsewere. The final contents formated in a simple XML construction will fit accurately in the locations that will be reserved for. Lets examine a first example : Consider this document abstract, that is, a user screenboard in a web-based application :
<%if ((%FORM::what% ne "documentation")
and (%FORM::what% ne "demos")
and (%AUTH::OK% ne "1")) %>
<DIV ID="member_result_shadow"
STYLE="position : absolute ;
display : block ;
width : 450px ;
height : 200px ;
top : 143px ;
left : 203px ;
background-color :
rgb(69,77,94)"></DIV>
<DIV ID="member_result"
STYLE="position : absolute ;
display : block ;
width : 450px ;
height : 200px ;
top : 140px ;
left : 200px ;
background-color :
rgb(200,0,0) ;
text-align : center ;
vertical-align : middle">
<TABLE WIDTH=90% BORDER=0 CELLSPACING=5 CELLPADDING=0>
<TR><TD ALIGN=right COLSPAN=2>
</TD></TR>
<TR>
<TD VALIGN=top>
<P CLASS="error"><B>Authentication Error.</B>
<P CLASS="error">Your login or your password is wrong. You are not admitted in the download zone.
<P CLASS="error"><A
HREF="Javascript:history.back()"
CLASS="error">Downloads gate</A>
</TD>
</TR>
</TABLE>
</DIV>
<%endif %>
It will allow displaying a pseudo dialog box when an error condition is detected.
Who is responsible for the message semantic will only care on the following elements : "Authentication error." , "Your login or your password is wrong. You are not admitted in the download zone." et "Downloads gate". Any other code sequence will encode either structure (DIV, location, conditional DIML expression, etc.), or formatting (classes , STYLE attributes, etc.). This example sequence does not contain any significant dynamic (process) encoding. The XML Gateway of the DIML processor allows using a separate XML file to define this sentences in a very clean and readable way, and provides the DIML a mean to extract and inject these content elements in their appropriate locations in the DIML flow. The above file would be separated in a XML file : <?xml version="xml1.0" ?> <error> <title>Authentication error.</title> <text>Your login or your password is wrong. You are not admitted in the download zone.</text> <link_label>Downloads gate</link_label> </error> close to a DIML injection framework :
<%if ((%FORM::what% ne "documentation") and (%FORM::what% ne "demos")
and (%AUTH::OK% ne "1")) %>
<DIV ID="resultat_membre_shadow" STYLE="position : absolute ;
display : block ;
width : 450px ;
height : 200px ;
top : 143px ;
left : 203px ;
background-color :
rgb(69,77,94)"></DIV>
<DIV ID="resultat_membre" STYLE="position : absolute ;
display : block ;
width : 450px ;
height : 200px ;
top : 140px ;
left : 200px ;
background-color : rgb(200,0,0) ;
text-align : center ;
vertical-align : middle">
<TABLE WIDTH=90% BORDER=0 CELLSPACING=5 CELLPADDING=0>
<TR><TD ALIGN=right COLSPAN=2>
</TD></TR>
<TR>
<TD VALIGN=top><P CLASS="error"><B><%%error::title%%></B>
<P CLASS="error"><%%error::text%%>
<P CLASS="error">
<A HREF="Javascript:history.back()" CLASS="error"><%%error::link_label%%></A>
</TD>
</TR>
</TABLE>
</DIV>
<%endif %>
The XML Gateway for the DIML MUST :
3.2 Limits Of The GatewayThe XML Gatexay WILL NOT verify the well-formed status of the document. Verifying conformance to a DTD would add much overhead to the production process and would affect performances. Documents are assumed being well-formed in a general XML context, that is having correct SGML element/attribute constructs. The Gateway WILL NOT consider, process, and apply any XSL rule or stylesheet call. The Gateway IS NOT dedicated to become a complete XML parser. However, some syntaxes used in XSLT filters may be used by the gateway to avoid confusion, and when exact or very similar semantic can be kept. The content of XML elements may contain:
4. XML Identifier Translation4.1 The DIML Namespace4.1.1 Naming Rules In The DIML NamespaceDIML keeps free the organization of namespaces and scoping segmentation by using extended characters in the variable names. The variable external delimiter %...% allow such use of extended character set. Variables name such as:
uses inhabitual characters compared to C, Java, or other languages usual tokens. This syntactic flexibility will allow the developer to express its own syntactic semantics, denoting for some pseudo-behaviour of such variables. As in the above examples:
Extra symbol set will open to a wide range of new semantics, pursuant the unicity of the DIML identifier is preserved. However the identifier is constructed, the ESSI processor does not care at the implicit or conventional meaning intended by the developer. The semantic of the variable remains under developer's own responsibility.
The DIML specification 1.0 defines some standard scopes that were recognized in the first implementations of the ESSI processor. The ESSI processor uses the following scopes:
The ESSI processor in version 2.1 adds a new standard scope:
4.1.3 Translation ConstraintsXML element integration in a DIML document framework assumes names are translated in a name scope that the DIML has access to. Constructing such scope needs some constraints to be worked with:
4.2 Constructing The DIML Name4.2.1 Identifying The ElementInjecting XML elements assumes opening of an XML file occured (!) and the elements have been identified. Analysing a XML file to identify elements needs a three stage process:
4.2.2 Identifying the sourceOn a theoretic approach, discriminating the source of the data should rely on an URI, and would enjoin us to use a fully specified identifier as: /home/diml/xml/xmlsample.xml#root.box1(@id=='2').box2.element.innerText or, if the file is a network reachable file: http://www.diml.net/xml/xmlsample.xml#root.box1(@id=='2').box2.element.innerText Practically, manipulating fully specified references should be avoided, for all advantages of the HTML meta-tagging (i.e. keeping the source flow as readable as possible) would be lost. We proposed another way to discriminate data injected from distinct sources but having the same internal structure. The XML to DIML translation will operate a distinct indirection defining a distinct scope for generated variables each time an %xml statement is called (see the scope attribute).
Translation output identifiers are available as other DIML variables, according to the following scheme: <%%scope_id::XML_tree_identifier%%> in which :
XML_tree_identifier ::= [ *[ node_id "." ] XML_tree_identifier ] | node_id
node_id ::= element_id ?[ "(" selector ")" ]
element_id ::= #NMTOKEN
selector ::= #CDATA | [ quotemark #CDATA quotemark ]
quotemark ::= '"'
Specifying a selector value needs an explicit selector has been used in the "<%xml" statement or an ordinal default selection was made (implicit @@ selector). Elemtns that have single descenant resolution will not have any explicit selector. When an element has multiple descendance, and no selector has been defined, all the childs will be affected the value of the default ordinal counter @@ as discriminator. Note 1: The ordinal selector @@ counts the instances of a specific child element within its father's scope. Its value will alway be 0 for the first child instance. Childs as distinct elements will have independant counters. Note 2: The selector name has been hidden in the syntax of the XML element identifer to shorten the expression. Thez consequence is that no more than one selector can be used for a specific XML tree node. This selector is :
A further release of this documentation will argue on if this specification is too restrictive or not.
Let consider the following XML file:
<?xml version="xml1.0" ?>
<root>
<box1 id="1">
<box2>
du contenu de box2
<element attrib1="value1" attrib2="value2">sample a</element>
<element attrib2="value2" attrib1="value2">sample b</element>
</box2>
</box1>
<box1 id="2">
<box2>
<element attrib1="value1">sample2</element>
<souselement>subsample1</element>
<souselement>subsample2</element>
<souselement>subsample3</element>
<souselement>subsample4</element>
</box2>
</box1>
</root>
The expanded access keys below are valid:
4.3.3 Short formShort form is usefull when extracting data from document that have been generated by XML capable authoring applications, when document structure and density is much heavier than simple data sheets based on trivial DTDs. Complexity of real life documents set limits to usability of the expanded form, because of the deepness of the element tree. Some data may nevertheless be fetched deeply within the document structure. Short form of translated identifiers allow in some way extracting data in this context, without getting DIML flow too inextricable. 5 The %xml statement5.1 Common syntaxUsing variables from an XML flow assumes a previously executed call that describes and processes the XML data, and passes values to a translated DIML variable set. This results in a brand new DIML statement which general form is : <%xml source="filename" scope="variable_scope" select="XML_selector" alias="alias_prefix" %> Here is an application for a local 'relatively accessed) XML file : <%xml source="../xml/xmlsample.xml" scope="SAMP1" select="box1(@id=~'valid')" %> 5.2 The source attributeThe source attribute specifies the XML source file. It may contain a valid physical URI depending on the actual operating system conventions. Alternatively (version 3.0 of the DIML processor) this attribute should be associated to a DIML symbol, containing a well-formed XML sequence. Examples : <%xml source="../xml/sample.xml" -> relative physical access <%xml source="D:/dimlweb/xml/sample.xml" -> Windows absolute access <%xml source="/home/www/dimlweb/xml/sample.xml" -> Unix/Linux absolute access <%xml source=%XML_SEQUENCE% -> localized XML fragment 5.3 The scope attributeThe scope attribute defines the DIML variable range the produced variables will be set in. This scope can be any DIML valid name using any char excepting %, [, ], '\n' nor '\r'. Note : scoping prefixes having included subscope separation (::) are allowed. Scope names should not be scope (::) terminated (i.e. the DIML engine adds the scoping separator), although the DIML processor is not told to verify this situation. Examples : <%xml source="../foo.xml" scope="XMLDATA" ... <%xml source="../foo.xml" scope="XML::FOO" ... Variables generated after DIML translation should start respectively with prefixes "XMLDATA::" and "XML::FOO::". Scoping output variable sets is valuable when multiple XML documents are opened sharing the same DTD. 5.4 The select attributeThe select attribute is obviously the hardest to explain. It acts as a selector (XSL-like) on the source XML tree, to reduce the number of sybols the translation generates in the DIML variable space. Selection can point to a unique element, a recurrent element at a defined hierarchy level, an element coping a particular DTD define, or which has some precise values for some attributes. 5.4.1 Common form of the selectorSelecting an element in an XML flow assumes resolving an access path to that element in the XML name structure. In order to reach the element's value, some tree nodes should be evaluated, in the right order, and be applied a selection filter. The common form of the selector is a dotted sequence of element identifiers, denoting an inclusion path from the XML root element. The common form of this matches the following BNF definition (Bakkus-Naur Form):
XML_tree_identifier ::= [ *[ node_id "." ] XML_tree_identifier ] | node_id
node_id ::= element_id ?[ "(" selector ")" ] | '*'
element_id ::= #NMTOKEN | '*'
selector ::= [ *selector_expr "," selector ] | selector_expr
selector_expr ::= var_name [ pattern_operator pattern | comparison_operator operand ]
var_name ::= "@" attribute_id
comparison_operator ::= "=" | "<" | ">" | "<=" | ">=" | "!="
operand ::= #CDATA | [ quotemark #CDATA quotemark ] | '*'
quotemark ::= '"'
pattern_operator ::= "=~" |"!~"
pattern ::= #EREGEXP
#EREGEXP is a POSIX 2 extended regular expression. At a single node stage, selection uses existing attributes as a node discriminator. This specification does not reclaim any behaviour in case multiple "brothers" elements share the same attribute value set (non integral discrimination). Anyway, this specification assumes the complete signature of the element (element name + attribute set) is a unique discriminator for any node in the XML document. Please note some following definitions before continuing reading this specification:
5.4.2 Selection of one single XML valueElement selection is considered as having a unique solution when the following conditions are matched:
5.4.3 Selecting an element by its referenceThe selector stopping with an element name, without telling any attribute nor a special meta-attribute within "innerText", "innerHtml" or "innerXml" is called "reference selection int he XML tree". this selector form extracts the XML subtree contained as content of the discriminated element. It is strictly equivalent to applying for the "innerXml" attribute. Example : to be written... 5.4.4 Extracting XML element attributesShould be considered that attribute values of XML element are also containing usefull information. the unique selector should be able to point to attribute values of a discriminated node. Any valid attribute of an XML element will thus be reachable using a selector of the generic following syntax: XML_attribute_identifier ::= XML_tree_identifier ] "." attribute_id | reserved_attribute reserved_attribute ::= "innerText" | "innerXml" | "innerHtml" XML_tree_identifier was defined previously in this specification. The implicit "innerText", "innerXml" and "innerHtml" are metas.
La sélection du contenu d'un élément XML peut signifier plusieurs choses. Lorsque la source de données est un document linéaire, que le XML signale en terme de qualification d'éléments, il est possible de considérer la séquence de contenu littérale contenue dans cet élément. Par exemple, si l'on considère le fragment XML suivant :
<root>
<adresse>
<numero>20</numero>
<voie>Av du Parc</voie>
<codeposte><I>95011</I></codeposte>
<ville>CERGY</ville>
<pays>FRANCE</pays>
</adresse>
</root>
il peut être souhaîtable de récupérer la totalité de l'adresse comme un seul fragment texte. C'est le rôle de l'attribut "innerText" qui détruit tout balisage inférieur au niveau d'élément auquel il est appliqué dans le sélecteur. Par exemple, le sélecteur : adresse.innerText construit bien une variable unique contenant la séquence : 20 Av du Parc 95011 CERGY FRANCE On remarque ici que les fins de ligne sont respectés à l'intérieur de l'élément "adresse", de façon à ce que les données textualisées restent identifiables. Globalement, et pour simplifier l'analyse, ce sont tous les caractères d'espacement qui sont conservés par le filtre de textualisation.
L'attribut virtuel "innerXml" permet également d'obtenir une certaine interprétation de l'élément XML sélectionné par le filtre. Ce méta-attribut représente l'ensemble du contenu de l'élément XML sans aucun filtrage.
L'attribut virtuel "innerHtml" est la dernière forme de représentation du contenu qui admet de conserver d'éventuelles balises HTML lors de l'interprétation de l'élément. En reprenant l'exemple précédant, adresse.innerHtml construit une variable unique contenant la séquence
20 L'utilisation du méta '*' à la place d'un noeud de l'expression du sélecteur est possible, et indique qu'à ce niveau d'arbre, l'identité de l'élément est quelconque. Si une expression de sélection explicite est définie pour ce noeud (l'expression aura alors la forme "*(@selector operator operand)"), alors la résolution du sélecteur sera appliqué à tous les éléments occupant ce niveau d'arbre, même si l'attribut discriminant ne leur est pas applicable. Si tel est le cas, l'élément ne pourra être sélectionné.
L'attribut alias permet de réduire l'identifiant DIML translaté à une forme canonique dans laquelle seules les valeurs des sélecteurs sont mentionnées. L'objectif de cette canonisation est de rendre plus concises les variables d'arrivées et de mieux les intégrer dans le flux DIML. La valeur de cet attribut est un préfixe servant à générer le nom de variable. La formation de la variable translatée est différente en fonction du résultat du sélecteur :
| |||||||