/
niceSOFT
/
libxslt
Обзор
Документация
Войти
/
niceSOFT
/
libxslt
Код
Задачи
Вики
Пакеты
0
Релизы
0
Аналитика
Безопасность
master
NOTES
252 строки
7 KB
Daniel Veillard
Initial revision
07 янв 2001, 17:01
07 янв 2001, 17:01
6f5e152
Код
Авторство
О чём код?
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.