Permalink
Browse files

Initial revision

  • Loading branch information...
1 parent 8a5bfd8 commit 6f5e152012186758087a2eead15199e795f8e192 Daniel Veillard committed Jan 7, 2001
Showing with 1,168 additions and 0 deletions.
  1. +10 −0 AUTHORS
  2. +17 −0 ChangeLog
  3. +29 −0 Makefile.am
  4. +7 −0 NEWS
  5. +253 −0 NOTES
  6. +12 −0 README
  7. +71 −0 autogen.sh
  8. +7 −0 config.h.in
  9. +105 −0 configure.in
  10. +25 −0 libxslt/Makefile.am
  11. +54 −0 libxslt/xslt.c
  12. +28 −0 libxslt/xslt.h
  13. +36 −0 libxslt/xsltInternals.h
  14. +37 −0 libxslt/xsltproc.c
  15. +19 −0 tests/Makefile.am
  16. +7 −0 tests/REC1/doc.dtd
  17. +17 −0 tests/REC1/doc.xml
  18. +62 −0 tests/REC1/doc.xsl
  19. +18 −0 tests/REC1/result.xml
  20. +21 −0 tests/REC2/data.xml
  21. +22 −0 tests/REC2/html.xml
  22. +43 −0 tests/REC2/html.xsl
  23. +18 −0 tests/REC2/svg.xml
  24. +45 −0 tests/REC2/svg.xsl
  25. +37 −0 tests/REC2/vrml.xml
  26. +34 −0 tests/REC2/vrml.xsl
  27. +127 −0 xslt-config.in
  28. +7 −0 xsltConf.sh.in
View
10 AUTHORS
@@ -0,0 +1,10 @@
+
+Daniel Veillard:
+ Daniel.Veillard@imag.fr
+ DV on #gnome IRC channel
+ http://veillard.com/
+ Used to work at W3C, now Red Hat
+ co-chair of W3C XML Linking WG
+ invited expert on the W3C XML Core WG
+ Author of libxml upon which this library is based.
+
View
@@ -0,0 +1,17 @@
+Sun Jan 7 13:51:30 CET 2001 Daniel Veillard <Daniel.Veillard@imag.fr>
+
+ * libxslt/xslt.[ch] libxslt/xsltInternals.h libxslt/xsltproc.c:
+ first steps toward building the framework
+
+Sun Jan 7 12:22:13 CET 2001 Daniel Veillard <Daniel.Veillard@imag.fr>
+
+ * NOTES: added notes taken while reading the spec.
+
+Fri Jan 5 11:34:12 CET 2001 Daniel Veillard <Daniel.Veillard@imag.fr>
+
+ * test/REC1 test/REC2: added examples from the XSLT REC
+
+Fri Jan 5 11:14:29 CET 2001 Daniel Veillard <Daniel.Veillard@imag.fr>
+
+ * README: basic informations
+ * Changelog: created
View
@@ -0,0 +1,29 @@
+SUBDIRS = \
+ libxslt \
+ tests
+
+confexecdir=$(libdir)
+confexec_DATA = xsltConf.sh
+
+bin_SCRIPTS = xslt-config
+
+EXTRA_DIST = xsltConf.sh.in xslt-config.in
+
+
+## We create xsltConf.sh here and not from configure because we want
+## to get the paths expanded correctly. Macros like srcdir are given
+## the value NONE in configure if the user doesn't specify them (this
+## is an autoconf feature, not a bug).
+
+xsltConf.sh: xsltConf.sh.in Makefile
+## Use sed and then mv to avoid problems if the user interrupts.
+ sed -e 's?\@XSLT_LIBDIR\@?$(XSLT_LIBDIR)?g' \
+ -e 's?\@XSLT_INCLUDEDIR\@?$(XSLT_INCLUDEDIR)?g' \
+ -e 's?\@VERSION\@?$(VERSION)?g' \
+ -e 's?\@XSLT_LIBS\@?$(XSLT_LIBS)?g' \
+ < $(srcdir)/xsltConf.sh.in > xsltConf.tmp \
+ && mv xsltConf.tmp xsltConf.sh
+
+
+
+
View
7 NEWS
@@ -0,0 +1,7 @@
+Sun Jan 7 14:54:28 CET 2001
+ Creating libxslt project in Gnome CVS base
+
+Fri Jan 5
+ Started reading the XSLT 1.0 spec:
+ http://www.w3.org/TR/xslt
+ W3C Recommendation 16 November 1999
View
253 NOTES
@@ -0,0 +1,253 @@
+
+ NOTES relative to the implementation
+ ====================================
+
+xsl:stylesheet:
+
+ all children except xsl:import can be in any order, so this
+can be stored as one big structure.
+
+xsl:include:
+
+ this is really similar to XInclude, can be implemented as a
+nearly separate processing just after the XML stylesheet has been
+parsed.
+ Detect loops using a limited stack ...
+
+xsl:import:
+
+ seems this should be really implemented as having a stylesheet
+sublist being itself an import list
+
+ add the list at the end
+ when doing a resolution explore child before siblings in the list
+
+3 Data Model, we should operate on parsed trees
+
+3.1 No problem
+
+3.2 use the XML Base call, XSLT-1.1 references it
+
+3.4 Whitespace Stripping
+
+ Seems one may have to do a bit of preprocessing on both the
+stylesheet trees and the source trees.
+
+4 Expressions
+
+ looks okay, wondering about variable bindings though...
+ default namespace not in scope
+
+5.1 Processing Model
+
+ look in Michael Kay's book about how to efficiently find the
+template applying to a node. Might influence the in-memory stylesheet
+representation
+
+5.2 Patterns
+
+ the end of that section suggest that the expression could be computed in
+a simpler way. Maybe templates needs to be evaluated differently than
+through the normal XPath processing. This can be implemented separately
+or build an expression tree in the XPath module and use a different
+evaluation mechanism. Not sure this is best.
+
+5.4 Applying Template Rules
+
+ xsl:apply-templates is the recurstion mechanism, note the select
+mechanism.
+
+ detection of loop: once the applied nodeset has been computed,
+check that none of the elements is part of the existing set in use, this
+may be costly and should be triggered only at a certain depth.
+
+5.5 Conflict Resolution for Template Rules
+
+ Sounds again that evaluation of a pattern rule should provide one
+more information not provided by the standard XPath evaluation
+
+5.6 Overriding Template Rules
+
+ another recursion mechanism, confirm that it is needed to separate
+the imported stylesheets.
+
+5.7 Modes
+
+ Confusing ??? need an example.
+
+6 Named Templates
+
+ No big deal it seems
+
+7.1.1 Literal Result Elements
+
+ cleanup of the namespace template should be done initially at stylesheet
+parsing.
+
+7.1.2 Creating Elements with xsl:element
+
+ okay, I bet it's usually used with { } expression computations
+
+7.1.3 Creating Attributes with xsl:attribute
+
+ need some running code to better understand all the subtilties
+
+7.1.4 Named Attribute Sets
+
+ Okay just a way to mimick param entities use fo attrib groups in Dtd's
+
+7.2 Creating Text
+
+ adjacent text nodes are merged ... okay
+ output escapeing might need a libxml API extension
+
+7.3 Creating Processing Instructions
+7.4 Creating Comments
+
+ RAS, one just need to make a couple of trivial checks
+
+7.5 Copying
+
+ Okay will need some testing
+
+7.6.1 Generating Text with xsl:value-of
+
+ will be a good test for XPath string() function
+ note in the example that the text nodes are coalesced
+
+7.6.2 Attribute Value Templates
+
+ hum, this is
+ - contextual
+ - uses XPath
+
+ best seems to parse, generate an evaluation tree then evaluate
+when accessed. Note that multipe expressions can be associated to
+a single attribute. Sounds like i will have to introduce a new
+element type inserted in the attribute nodelist. dohh ...
+
+7.7 Numbering
+
+ sounds interesting for users but might be costly, we will see ...
+
+7.7.1 Number to String Conversion Attributes
+
+ format="..." :-( it's gonna be painful ...
+
+8 Repetition
+9 Conditional Processing
+
+ doesn't sounds hard to implement since we are at an interpreter
+level but really useful in practice. Will be simple once the overall
+framework is set-up.
+
+10 Sorting
+
+ Okay applied to the node list of an xsl:apply-templates or xsl:for-each
+
+ The NOTEs are a bit scary ...
+
+11 Variables and Parameters
+
+ Variables can only be afttected at the top level, so it
+seems they act only as global variables ...
+ But this is by regions .... so some of the statements within
+a stylesheet my use a different set than others ... in practice
+it turns to be nearly like loacal variables ....
+ Need more thinking on this to handle it properly.
+ Might explain on of TOM's requests w.r.t. variable resolution
+
+11.1 Result Tree Fragments
+
+ Dohhh a new type ...
+ actually it's just a node set restricted type
+
+11.2 Values of Variables and Parameters
+
+ okay, real problem is scoping ...
+
+11.3 Using Values of Variables and Parameters with xsl:copy-of
+
+ No surprize
+
+11.4 Top-level Variables and Parameters
+
+ It is an error if a stylesheet contains more than one binding
+ of a top-level variable with the same name and same import precedence
+
+ => ah ah, so it seems one can associate the variable bindings
+to a stylesheet and if needed recurse down the import list if not
+found, would simplify things a lot !
+
+ If the template or expression specifying the value of a global variable
+x references a global variable y, then the value for y must be computed
+before the value of x.
+
+ => Values can probably be computed dynamically at reference
+time, if this generate a loop, then it's an error. Lazy computations
+are great ...
+
+11.5 Variables and Parameters within Templates
+
+
+ xsl:variable is allowed anywhere within a template that an instruction
+is allowed. In this case, the binding is visible for all following siblings
+and their descendants.
+ It is an error if a binding established by an xsl:variable or xsl:param
+element within a template shadows another binding established by an
+xsl:variable or xsl:param element also within the template.
+
+ => the example seems to imply that we can simply keep a list of
+ local variable binding to a template ... sounds fine.
+
+11.6 Passing Parameters to Templates
+
+ => Okay the parameter overrides the local binding
+
+12.1 Multiple Source Documents
+12.2 Keys
+
+ skipped for now
+
+12.3 Number Formatting
+
+ reimplementing Java formatting in C is gonna be a pain !
+
+12.4 Miscellaneous Additional Functions
+
+ current() => trivial
+
+ unparsed-entity-uri() => support in uri.c should do
+
+ generate-id() => use the in-memory address of the node ???
+
+ system-property() => sounds simple
+
+13 Messages
+
+ trivial I/Os
+
+14 Extensions
+15 Fallback
+
+ skipped for now
+
+16 Output
+
+16.1 XML Output Method
+
+ sounds that calling directly libxml output on the result tree
+should do it with a few caveats, for example one need to be
+able to parametrize the output
+
+16.2 HTML Output Method
+
+ sounds that calling libxml HTML output should do it too
+
+16.3 Text Output Method
+
+ doesn't sounds too hard ...
+
+16.4 Disabling Output Escaping
+
+ hum ... might be a bit painful to implement with the current framework.
View
12 README
@@ -0,0 +1,12 @@
+
+ XSLT support for libxml
+
+ http://xmlsoft.org/
+
+ Requires libxml2 with XPath support.
+Currently unusable, very early steps ...
+
+Daniel Veillard
+
+Daniel.Veillard@imag.fr
+$Id$
Oops, something went wrong.

0 comments on commit 6f5e152

Please sign in to comment.