This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20483 - [Templates]: Specify the behavior of XDM when encountering <template> element
Summary: [Templates]: Specify the behavior of XDM when encountering <template> element
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 15476
  Show dependency treegraph
 
Reported: 2012-12-21 20:27 UTC by Rafael Weinstein
Modified: 2013-01-24 17:41 UTC (History)
3 users (show)

See Also:


Attachments

Description Rafael Weinstein 2012-12-21 20:27:44 UTC
XPath transforms used by XSLT during initial construction should traverse through template content, but direct XPath DOM API calls should not.

(I need to do a fair bit more digging in the spec to be able to more accurately describe the problem and solution here).
Comment 1 Rafael Weinstein 2012-12-21 20:31:48 UTC
Also, ensure that the output of XSTL, if it contains templates, is parsed correctly (i.e. template content *is* lifted and appended into the template content document fragment).
Comment 2 Rafael Weinstein 2013-01-09 00:30:13 UTC
Ok. Looking at this more, I think I get it. Here's what I see. Henri, tell me if this is right:

-XSLT output must produce DOM "as if" it were parsed by XML (i.e. template contents go through the "worm hole". This must be the case for XSLTProcessor as well.

-XPath DOM queries DO NOT traverse through the "worm hole"

-XSLTProcessor directives DO traverse through the "worm hole" when processing the "source" DOM.
Comment 3 Henri Sivonen 2013-01-09 07:54:38 UTC
(In reply to comment #2)
> Ok. Looking at this more, I think I get it. Here's what I see. Henri, tell
> me if this is right:
> 
> -XSLT output must produce DOM "as if" it were parsed by XML (i.e. template
> contents go through the "worm hole". This must be the case for XSLTProcessor
> as well.
> 
> -XPath DOM queries DO NOT traverse through the "worm hole"

document.evaluate, that is.

> -XSLTProcessor directives DO traverse through the "worm hole" when
> processing the "source" DOM.

Yes, looks right.
Comment 4 Rafael Weinstein 2013-01-22 21:26:08 UTC
https://dvcs.w3.org/hg/webcomponents/rev/f33622c39c5e

I'm reluctant to say anything about XDM directly here. I'm hoping this is sufficient.

Henri, if you're not happy with this, can you please suggest some appropriate wording.
Comment 5 Henri Sivonen 2013-01-23 09:29:52 UTC
(In reply to comment #4)
> https://dvcs.w3.org/hg/webcomponents/rev/f33622c39c5e
> 
> I'm reluctant to say anything about XDM directly here. I'm hoping this is
> sufficient.
> 
> Henri, if you're not happy with this, can you please suggest some
> appropriate wording.

I'd say something explicitly about the XPath API and not talk about serialization, because XSLT doesn't operate on serialization and the template spec changes the relationship of the serialization and the tree. Also, I'd avoid "should" in non-normative text. Something like:

<p><em>Non-normative note: XSLT processing ought to treat template contents as descendants of the template element in XSLT input and place the descendants of a template element into template contents in XSLT output. However, XPath evaluation using the XPath DOM API ought not to match on template contents.</em></p>
Comment 6 Henri Sivonen 2013-01-23 09:30:53 UTC
Oh, and why non-normative? Political reasons? It's an interop-sensitive statement after all.
Comment 7 Rafael Weinstein 2013-01-24 17:40:55 UTC
Changed per Henri's suggestion.

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#xslt-and-xpath
Comment 8 Rafael Weinstein 2013-01-24 17:41:39 UTC
tony, note the changed language on this in the previous comment.