path: root/NOTES

        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.