Your SlideShare is downloading. ×
  • Like
An Architecture for an XML-Template Engine enabling Safe Authoring
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

An Architecture for an XML-Template Engine enabling Safe Authoring

  • 227 views
Published

 

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
227
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Goals: Classification was important to make clear, what are the preconditions for Safe Authoring
  • This is the only slide repeated from my previous colloqium.
    One more thing to note: XTL = XML Template Language! Safe Authoring!
    Two main application areas: Generating Code (MDA) or generating markup languages (for Web front ends)
  • Erste Definition: Abgrenzung zu Aspekten unmöglich.
    Zweite Definition: Was ist ein Literal? Abgrenzung zu XSL-T unmöglich.
  • If an error should be detected upfront, the constraint that prevents it in the target language must be preserved in the template language.
  • Fehler: Shli
  • more classifications:
    placeholder – opaque, semantically meaningful, undefined
    deployment (all-in-one, frames…)
  • Prepares slides with the constraints for the three cases
  • Operational semantic of XTL Engine: Picture
  • Make a slide here? Two stage/dynamic Xpath evaluating XSL-T
  • Reidentification of XTL language element by sequence number

Transcript

  • 1. An Architecture for an XML-Template Engine enabling Safe Authoring Falk Hartmann Research Associate, SAP AG
  • 2. 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. 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! © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 3
  • 4. 4/25 Definitions Binding Language JSP <%= table.date() %> = Slot Markup Language + Term Language <%= © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 4 %> table.date()
  • 5. 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) © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 5 5/25
  • 6. 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. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 6
  • 7. 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. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 7
  • 8. 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. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 8
  • 9. Requirement 4: Control Goals: Separation of Concerns The binding language must support control statements for conditional and repeated inclusion of template fragments. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 9 9/25
  • 10. 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. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 10
  • 11. 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. © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 11
  • 12. Proposed Architecture © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 12 12/25
  • 13. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 13
  • 14. …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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 14
  • 15. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 15
  • 16. … 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> © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 16
  • 17. … 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> © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 17
  • 18. … 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> © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 18
  • 19. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 19 19/25
  • 20. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 20
  • 21. 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) © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 21
  • 22. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 22
  • 23. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 23
  • 24. 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 © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 24 24/25
  • 25. 25/25 Questions Thank you very much! Questions…? © SAP AG 2006, An Architecture for an XML-Template Engine… / Falk Hartmann / 25