Alessandro Bonazzi
8c43d5cf2f
Files correlati : cg0.exe cg0700a.msk cg0700b.msk cg3.exe cg4.exe Bug : Commento: Merge 1.0 libraries
254 lines
6.6 KiB
Plaintext
254 lines
6.6 KiB
Plaintext
|
|
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.
|