An Architecture for an XML-Template Engine enabling Safe Authoring

An Architecture for an XML-Template
Engine enabling Safe Authoring
Falk Hartmann
Research Associate, SAP AG

Agenda
Motivating Example
Definitions
Goals
Requirements
Proposed Architecture
Solution Elements
Related Work
Conclusion & Open Issues

© SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 2

2/25

3/25

Motivating Example
Author

Template
(JSP)

Servlet Container

JSP Engine

Page
(XHTML)

Browser
User

Data
Data Tier

Safe Authoring:
Ensure, that the instantiated template conforms to
the target language by inspecting the template!

4/25

Definitions

Binding Language
JSP <%= table.date() %>

= Slot Markup Language + Term Language
<%=


%>

table.date()

Goals
Safe Authoring
All errors detectable upfront are indeed detected upfront
Structural errors like incorrectly nested elements, missing attributes

Separation of Concerns
Templates are a mean for separation of concerns
Concerns depend on use case, e.g., between web designer and developer

Adequate Error Handling
Errors are clearly and understandably signaled to the user
Both for errors detectable upfront and at runtime

Broad applicability
Restriction on target language: XML
No restrictions on the instantiation data (esp. its addressing)


5/25

Requirement 1: Preservation

6/25

Goals: Safe Authoring
A template engine and language must preserve all constraints that
are valid in the target language also in the template language.


Requirement 2: Coverage

7/25

Goals: Broad Applicability, Separation of Concerns
The template language should cover the target language by allowing
to produce every target language document from a template, no
matter which parts of the target language document are created
from the instantiation data.


Requirement 3: Inferibility

8/25

Goals: Safe Authoring, Broad Applicability
It must be possible to automatically infer the schema the template
must comply to from the schema defined for the target language.


Requirement 4: Control
Goals: Separation of Concerns
The binding language must support control statements for
conditional and repeated inclusion of template fragments.


9/25

Requirement 5: Type safety

10/25

Goals: Adequate Error Handling
In order to assert, that the instantiated template complies to the
target language schema the types of the instantiation data must be
correct.


Requirement 6: Independence

11/25

Goals: Broad Applicability
The architecture should be independent of the data source and the
way data in it is addressed.


Proposed Architecture


12/25

Solution Element 1: Binding Language Design

13/25

Requirements: Coverage, Control, Independence
General:
 Independence makes reasoning about instantiation data impossible
⇒ No switch statements which allows multiple branches
 Coverage and control imply the necessity for conditional and repeated
content

XML Specific:
 Leverage namespaces as concept for slot markup language
⇒ No extra markup, existing tools can be reused
 XTL = XML Template Language
 Prototypical approach: XTL is embedded into target language
 Elements: xtl:text, xtl:attribute, xtl:if, xtl:for-each
 Decision against xtl:element

…Prototypical vs. Transformational Approach

14/25

Prototypical Approach:
Target language syntax is "top-level" syntax
Binding language syntax is embedded
JSP:

<html>…<%= name %>…</html>

+ target language syntax checkable (with limitations ⇒ improvable)
+ easier to learn

Transformational Approach:
Binding language syntax is "top-level" syntax
Target language fragments are embedded
XSLT:

<xslt:transform>…<html>…</html>…</xslt:transform>

+ binding language syntax checkable

Solution Element 2: Grammar Transformer

15/25

Requirements: Preservation, Inferibility
General:
 Separation of constraints: upfront checkable and instantiation data

XML Specific:
 Target language grammar (input): XML Schema
 Template language grammar (output): not expressible in XML Schema
→ enhancement of XML Schema with OCL constraints (CXSD)
 Schema without constraints should not declare valid templates invalid
 Instantiation data constraints: XML Schema Types
 Enabling xtl:attribute for all elements with attributes
 Enabling xtl:if/xtl:for-each around elements with appr. multiplicity
 Forcing ID to be replaced by xtl:attribute in xtl:for-each


… Enabling xtl:attribute

16/25

<element
Problem: name="external-graphic">
<annotation>
- Attribute might be substituted by xtl:attribute
<appinfo source="…">
- Change of content model and attribute model
<cxsd:inv>
let count : Integer =
Current Approach:
self->select(xtl:attribute[@name='src'])->size()
in
<element name="external-graphic">
if @src->isEmpty()
<complexType> count = 1 else count = 0 endif
then
<attribute name="src" type="string" use="required"/>
<sequence>
</cxsd:inv>
</complexType>
<element
</appinfo> ref="xtl:attribute"/>
</element>
</sequence>
</annotation>
<attribute
<complexType>name="src" type="string" use="optional"/>
</complexType>
<sequence>
</element>
<element ref="xtl:attribute"/>
</sequence>
<attribute name="src" type="string" use="optional"/>
</complexType>
</element>

… Enabling xtl:if/xtl:for-each

17/25

Problem:
- Modeling as attribute vs. as element
- Definition of xtl:if/xtl:for-each with wildcard (lax
processing)
- Problem: asserting local validity

Current Approach:
<element name="label" type="string" minOccurs="0"/>
<element ref="xtl:if">
<annotation>
<appinfo source="http://research.sap.com/cxsd/1.0">
<cxsd:element name="label" type="string"/>
</appinfo>
</annotation>
</element>


… Forcing ID to be replaced

18/25

Problem:
-Attributes and elements with type 'ID' must be instantiation data
inside xtl:for-each
-Treatment of IDREF unsolved (conversion to string?)

Current Approach:
<cxsd:inv>
let count : Integer =
self->select(ancestor::xtl:for-each->size())
in
count > 0 implies count(@id-attribute) = 0
</cxsd:inv>


Solution Element 3: Template Validator
Requirements: Preservation
General:
 Grammar checking tool
 Depending on template language grammar used

XML Specific:
 XML Schema with OCL constraints
 OCL navigation expressions replaced by XPath
 Implementation via XMLBeans and Dresden OCL Toolkit


19/25

Solution Element 4: Template Engine

20/25

Requirements: Control, Independence
General:
 Enable independence using plug-in architecture

XML Specific:
 Efficient (memory, time) implementation not straight-forward
 SAX implementation hard due to necessary look-ahead
 StAX allowed an efficient implementation based on a two-stream
machine
 Linear Memory and Time Complexity


Solution Element 5: Term Evaluator

21/25

Requirements: Independence
General:
 Term evaluation outsourced from template engine

XML Specific:
 Implementation of XPath plug-in makes XTL comparable to XSL-T
 XTL

cannot be translated directly to XSL-T as this would require dynamic
evaluation of XPath (however, with this feature or with a two-stage XSL-T it is
possible)

 Implementation of OCL plug-in planned
 OCL

plug-in would enable efficient generation of XML documents from UML
models (XMI, XML Schema using the corresponding profile)


Solution Element 6: Inst. Data Validator

22/25

Requirements: Type Safety
General:
 Enables exact error messages in case of mismatching instantiation data
types

XML Specific:
 Only simple types
 Straight-forward, check using XMLBeans


Related Work

23/25

• T. J. Parr:
Enforcing strict model-view separation in template engines.
WWW’04
• S. Maneth, A. Berlea, T. Perst, and H. Seidl:
XML type checking with macro tree transducers.
PODS’05
• M. Murata, D. Lee and M. Mani:
Taxonomy of XML Schema Languages using Formal Language
Theory.
Extreme Markup Languages 2001
• V. Wallentine, S. Zhou:
Validating XML Document Content with the Object Constraint
Language.
Documents in Computing and Information Science 2002


Conclusions & Open Issues
Conclusions:
- Safe authoring can be supported with this architecture
- XML Schema wildcards lack expressive power
- XML Schema transformations are hard to implement

Open Issues:
- Search existing XML Schema transformation engines
- Alternative schema languages
- Define white space handling
- Treatment of identity constraints


24/25

25/25

Questions

Thank you very much!

Questions…?


An Architecture for an XML-Template Engine enabling Safe Authoring

More Related Content

What's hot (8)

Similar to An Architecture for an XML-Template Engine enabling Safe Authoring (20)

More from Falk Hartmann (8)

Recently uploaded (20)

An Architecture for an XML-Template Engine enabling Safe Authoring

Editor's Notes