| |
| 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. |