1. EXPath A packaging system for XML libraries and a portable web application framework XML Prague, March 13 th , 2010 Florent Georges H2O Consulting

3. Simple examples

4. The packaging system

5. Web applications

6. A comprehensive example

7. Conclusion

9. XSLT 2.0 and needs for new extensions

10. EXSLT 2.0, EXQuery & EXProc

11. XML Prague 2009 – EXPath

12. First modules – HTTP Client & ZIP Facility

13. Balisage 2009 – the Packaging System

14. XML Prague 2010 – the Webapp module

16. Extensions for XPath of course

17. But also: XSLT, XQuery, XProc (and XForms, XML Schema, DSDL, etc.; that is, XML technologies)

18. Mainly extension functions

19. But also: servlet container, packaging system...

21. The main means is extension functions

22. The main goal is defining portable specifications...

23. ...and convincing vendors to endorse them

24. But also providing support to open-source implementations

26. The definitive goal is writing specifications

27. The main tool is the mailing list

28. Each module has one main maintainer, responsible of editing & achieving consensus

29. Other tools include Subversion repositories, public Wiki, etc.

30. More infos about processes on the wiki

32. Simple examples ←

33. The packaging system

34. Web applications

35. A comprehensive example

36. Conclusion

38. Get the description of the request as an XML element (with verb, headers, content...)

39. Return a description of the response as an XML element (with code, headers, content...)

40. Actually the content is handled differently (as separate items, either text, XML, HTML or binary) to avoid the SOAP envelope syndrome

41. Examples – HTTP Client http:send-request ( $ request as element (http:request)) as item () + <http:request href = &quot;http://www.example.com/...&quot; method = &quot;post&quot; > <http:header name = &quot;X-Header&quot; value = &quot;some value&quot; /> <http:body content-type = &quot;application/xml&quot; > <hello> World! </hello> </http:body> </http:request> <http:response status = &quot;200&quot; message = &quot;Ok&quot; > <http:header name = &quot;...&quot; value = &quot;...&quot; /> ... <http:body content-type = &quot;application/xml&quot; /> </http:response>

43. zip:html-entry ( $ href, $ path) as document-node ()

44. zip:text-entry ( $ href, $ path) as xs:string

46. zip:update-entries ( $ zip, $ output) as empty ()

47. Examples – Google Contacts

48. Examples – Google Contacts

50. Simple examples

51. The packaging system ←

52. Web applications

53. A comprehensive example

54. Conclusion

56. Depends on the processor

57. Easy: just copy the files somewhere

59. import module namespace ubl = &quot;http://fgeorges.org/ubl/mod-1&quot; at &quot;dadb://modules/ubl-helpers/mod-1.xql&quot; ;

61. So you have to change the import statements throughout this third-party library

62. Wait a minute, no problem, really, UBL Helpers have to include FunctX

63. But your application uses another library, which in turn also uses FunctX

64. ...

66. They help avoiding the requirement of changing import statements...

67. ...as long as everyone agree on URIs to use in import statements

68. They must then be supported by all products

69. One has to install configure catalogs for its system by hand, again and again

71. Must be understood by most processors (suitable for standard libraries)

72. Must package the components and additional informations in a single file (suitable as a delivery format)

74. Packaging – Overview

76. Command-line repository manager

77. Implementation for Saxon (XQuery, XSLT)

78. Implementation for Calabash (RELAX NG RNG + RNC, Schematron, XProc, XQuery, XML Schema and XSLT)

79. Implementations provide a Java API as well as command-line scripts

82. Other info can be added in the component source files

83. Structure and annotations captures some packaging information, used by a packager

85. They are as less as possible

86. Conventions are flexible

87. They can be used to ease developer's day-to-day life, by automating repetitive tasks

90. Simple examples

91. The packaging system

92. Web applications ←

93. A comprehensive example

94. Conclusion

96. Most existing XML databases provide proprietary framework for that (eXist, MarkLogic, Sausalito, etc.)

97. Then again, we are stuck with processor-locked applications

98. A standard would allow to write portable web applications, libraries and frameworks

100. A component can be an XQuery function or module, an XSLT function, template or stylesheet, or an XProc pipeline

101. The only technical missing piece is a way to map HTTP requests to components

102. That means dispatching and providing infos

104. A component is identified by its name (if applicable) and the import URI of it module

105. This is configured in a simple descriptor

106. ...and packaged using the Packaging System

107. The Packaging System already provides setting of the component's public URIs

108. The web descriptor simply builds on top of that

109. Webapps – Requests <web:request servlet = &quot;name&quot; path = &quot;/path&quot; method = &quot;get&quot; > <web:uri> http://example.org/my-app/path </web:uri> <web:authority> http://example.org </web:authority> <web:context-root> /my-app </web:context-root> <web:path> <web:part> path </web:part> </web:path> <web:header name = &quot;connection&quot; value = &quot;keep-alive&quot; /> ... </web:request> <web:response status = &quot;200&quot; message = &quot;Ok&quot; > <web:header name = &quot;...&quot; value = &quot;...&quot; /> ... <web:body content-type = &quot;text/html&quot; method = &quot;xhtml&quot; /> </http:response>

111. Server technology is Java Servlet

112. XSLT and XQuery are provided by Saxon

113. XProc is (going to be) provided by Calabash

114. Webapp manager to (un)deploy applications

116. Simple examples

117. The packaging system

118. Web applications

119. A comprehensive example ←

120. Conclusion

122. Use EXPath ZIP Facility

123. Use EXPath HTTP Client

124. Use Google API XSLT libraries

125. Use OAuth-like authentication

127. http://expath.org/