Wow! Neat to see more people getting into xsltc internals. Don't forget
about the long term plans to merge common parts of code betwixt the xalan
and xsltc engines (Scott, Morten, do we have basic plans posted on the web
anywhere? Obviously this might take a little while...)
-----------
> > * Change in XslAttribute; an xsl:attribute is allowed anywhere and adds
> > the attribute to the nearest containing result element. The check in
> > XslAttribute is not needed.
>
> I am not sure if I agree 100% here. Section 7.1.3 of the XSLT 1.0 spec
> states that it is an error to add attributes to an element E using the
> <xsl:attribute> element after adding child elements to E. Also, there
> are cases where some elements created with <xsl:element> are to be
> ignored and attributes have to be moved around - but only if they occur
> as the first child/children of an element.
In my mind, one of the prime goals is 100% spec compliance. I'd be
uncomfortable putting in stylesheet processing code that we know isn't
exactly up to the XSLT 1.0 spec. (and up to 2.0, when we really start in on
that).
> > * nwalsh'es stylesheets assume that "document('../common/l10n.xml')"
> > is taken relative to the root of the docbook stylesheets, but XSLTC
takes
> > it relative to the current directory at runtime. I don't know who's
right,
> > though XSLTC's position seems logical. However to make it work a
symlink
> > from ../common in your current directory to its real location is
> > necessary to make it run.
>
> Hmmmm.... this could make a good discussion. Inputs, anyone
We should be clear to document this kind of decision and (hopefully) make
sure it applies to both the xalan and xsltc engines. Also: what sort of
plans do we have to allow URIResolvers, etc. in xsltc-land?
- Shane
