- From: <bugzilla@jessica.w3.org>
- Date: Thu, 05 Apr 2012 02:11:53 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14734
Sandy Gao <sandygao@ca.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sandygao@ca.ibm.com
--- Comment #3 from Sandy Gao <sandygao@ca.ibm.com> 2012-04-05 02:11:50 UTC ---
> In the XSLT 2.0 schema for stylesheets
> ...
> If there is a global element declaration for 'book' ...
The "schema for stylesheets" clearly would not contain a declaration for
"book".
I suppose this can happen if the stylesheet is validated against a schema that
imports the XSLT schema? I'm not sure that's a useful thing to do (you can't
expect that your "book" in the stylesheet will contain what it normally
contains), especially given that the seemingly desired handling here is to
"skip" it (i.e. anything that's not in the XSLT schema will be ignored).
If we only consider the case where the stylesheet is validated against the
vanilla XSLT schema, then "lax" seems to work fine.
> If we could use NVDL, situation will be much better, we can strip elements in
> non-XSLT namespaces before validation and we can then use existing XSLT 2.0
> schema.
I'm not sure how that differs from validating the stylesheet as is against the
vanilla XSLT schema (with "lax"). Hm... there is (at least) one difference. If
there is an xsi:type or xsi:nil attribute on an LRE, then that will be taken
into account. Is this a significant enough case to worry about?
The one case where I think some of this could be useful is (as MikeK hinted in
his email) for syntax-directed editors, where it may be desirable to have both
the user schema and the XSLT schema in scope, so that help can be provided for
both xsl: elements and LREs. But for this case, "skip"/stripping aren't the
right answer for the LREs.
So I think a sensible editor can use the user+XSLT schema for things like
content assistance, and leave validation to the vanilla XSLT schema.
--
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 5 April 2012 02:11:55 UTC