1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
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.
|
