W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2006

[Bug 3070] How does "embedded simplified" work?

From: <bugzilla@wiggum.w3.org>
Date: Wed, 03 May 2006 15:42:21 +0000
CC:
To: public-qt-comments@w3.org
Message-Id: <E1FbJUb-0001bP-Hk@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3070





------- Comment #5 from david_marston@us.ibm.com  2006-05-03 15:42 -------
(1) is an excellent clarification. It is now clear that if you want to have an
embedded simplified, you cannot have an XSLT instruction element as the
outermost element. A further implication is that there exist XML documents that
cannot qualify for any of the four kinds of stylesheet module; more on that
below.

(2) restricts embedding to be within an XML document, as does the definition of
embedded two paragraphs below it in the CR. This is a change from XSLT 1.0,
which allowed embedding in a non-XML resource. Not that *I* would complain
about that. More on this topic at (6) below.

(5) is a good addition. I think you should also state initial mode and
stylesheet params can't be used (or have no effect), so that we know that the
WG discussed it and it's not just an error of omission.

(6) refers to "the containing XML document" as opposed to "the containing
document" which I take as a signal that you don't want to allow embedding in a
non-XML resource. The introduction to the two new bullet items signals to me
that you don't want to provide an exhaustive list of all the ways that
embedding can occur. Perhaps you want to say something to indicate other
possibilities exist?

When considering embedded stylesheets, there are two situations where you need
a method of locating the stylesheet module:
1. How it is identified at launch time as the "principle stylesheet module"
(term used in 2.3, defined in 1.1)
2. How it is identified for import/include (as required in 3.10.1)
Both of these are implementation-defined, and I don't see anything to indicate
that the mechanisms for methods 1 and 2 above must have anything in common.
Much of my conversation with Scott Boag was about whether it is adequate to
provide the whole containing document and leave the implementation to detect
the start of the stylesheet module, or whether the intent was that some precise
pointer must be provided, analogous to the launch option of identifying an
initial context node for the transformation input. Michael Kay argues for the
precise pointer when he says: "I think it's up to the user invoking a
transformation to identify the stylesheet they want to use (by identifying the
element at the root of the tree containing the stylesheet module)..." (from
comment #3). This issue is especially interesting for the case where the input
has an embedded stylesheet for transforming itself but does not have the
xml-stylesheet PI.

If you launch a transformation with an XML document and indicate that it is to
transform itself, and the outermost element is not xsl:stylesheet or
xsl:transform, what rules apply? Clearly, you don't want built-in rules to take
effect until some form of stylesheet module has been identified. More
pointedly, at some point the processor could recognize that the document is not
qualified to be any of the four kinds of stylesheet module; what error codes
are needed? I don't think that XTSE0150 and XTSE0165 cover all possible
situations.
Received on Wednesday, 3 May 2006 15:42:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:29 UTC