Implement a part of ProcessingInstruction by using PrivateScript

Implement a part of ProcessingInstruction by using PrivateScript

BUG=367689

[abarth-chromium, 2014-08-05 18:51:41]

https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
Source/core/dom/Document.idl:221: [OnlyExposedToPrivateScript] readonly
attribute Document transformSourceDocument;
I'm concerned about adding a bunch of private APIs to support XSLT-in-JS.  Do
you have a design doc that explains what private APIs we'll need?

It seems like applyXSLTransform and transformSourceDocument could be implemented
in JavaScript.  Is that the eventual plan?  For example, you could imagine
implementing XSLT processing directives entirely in JavaScript based on
window.XSLTProcessor...  In that approach, you wouldn't need these private APIs.

[tasak, 2014-08-06 02:52:03]

https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
File Source/core/dom/Document.idl (right):

https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
Source/core/dom/Document.idl:221: [OnlyExposedToPrivateScript] readonly
attribute Document transformSourceDocument;
On 2014/08/05 18:51:41, abarth wrote:
> I'm concerned about adding a bunch of private APIs to support XSLT-in-JS.  Do
> you have a design doc that explains what private APIs we'll need?
> 
> It seems like applyXSLTransform and transformSourceDocument could be
implemented
> in JavaScript.  Is that the eventual plan?  For example, you could imagine
> implementing XSLT processing directives entirely in JavaScript based on
> window.XSLTProcessor...  In that approach, you wouldn't need these private
APIs.

Yeah, I would like to remove applyXSLTransform and transformDocument from
Document.{h,cpp}.

However, I think, probably we need C++ special method for PrivateScript, i.e.
- setXSLStyleSheet, and
- createDocumentFromSource

setXSLStyleSheet is a special method to specify XSLStyleSheet, but
XSLTProcessor.idl provides importStyleSheet.

createDocumentFromSource replaces a current frame's document, e.g. XMLDocument
(before applying XSLStyleSheet) => HTMLDocument (after applying XSLStyleSheet).

The above methods are used in Document::applyXSLTransform but not public in web.

My plan is:
- some part of C++ applyXSLTransform will be re-implemented by using 
Javascript,
- the left C++ applyXSLTransform is moved into XSLTProcessor (private method for
PrivateScript).
- transformSourceDocument will be re-implemented by using Javascript

[haraken, 2014-08-06 03:30:11]

On 2014/08/06 02:52:03, tasak wrote:
>
https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
> File Source/core/dom/Document.idl (right):
> 
>
https://codereview.chromium.org/365873002/diff/60001/Source/core/dom/Document...
> Source/core/dom/Document.idl:221: [OnlyExposedToPrivateScript] readonly
> attribute Document transformSourceDocument;
> On 2014/08/05 18:51:41, abarth wrote:
> > I'm concerned about adding a bunch of private APIs to support XSLT-in-JS. 
Do
> > you have a design doc that explains what private APIs we'll need?
> > 
> > It seems like applyXSLTransform and transformSourceDocument could be
> implemented
> > in JavaScript.  Is that the eventual plan?  For example, you could imagine
> > implementing XSLT processing directives entirely in JavaScript based on
> > window.XSLTProcessor...  In that approach, you wouldn't need these private
> APIs.
> 
> Yeah, I would like to remove applyXSLTransform and transformDocument from
> Document.{h,cpp}.
> 
> However, I think, probably we need C++ special method for PrivateScript, i.e.
> - setXSLStyleSheet, and
> - createDocumentFromSource
> 
> setXSLStyleSheet is a special method to specify XSLStyleSheet, but
> XSLTProcessor.idl provides importStyleSheet.
> 
> createDocumentFromSource replaces a current frame's document, e.g. XMLDocument
> (before applying XSLStyleSheet) => HTMLDocument (after applying
XSLStyleSheet).
> 
> The above methods are used in Document::applyXSLTransform but not public in
web.
> 
> My plan is:
> - some part of C++ applyXSLTransform will be re-implemented by using 
> Javascript,
> - the left C++ applyXSLTransform is moved into XSLTProcessor (private method
for
> PrivateScript).
> - transformSourceDocument will be re-implemented by using Javascript

Can you add a link to your design document?

[abarth-chromium, 2014-08-06 04:12:53]

On 2014/08/06 at 02:52:03, tasak wrote:
> However, I think, probably we need C++ special method for PrivateScript, i.e.
> - setXSLStyleSheet, and
> - createDocumentFromSource
> 
> setXSLStyleSheet is a special method to specify XSLStyleSheet, but
XSLTProcessor.idl provides importStyleSheet.

I'm not sure I understand what setXSLStyleSheet would do.  Why does the document
care whether it has an XSLStyleSheet?

> createDocumentFromSource replaces a current frame's document, e.g. XMLDocument
(before applying XSLStyleSheet) => HTMLDocument (after applying XSLStyleSheet).

Have you considered the following API:

partial interface Window {
    void replaceDocument(Document document);
}

That would replace window.document with the document you pass in. 
Alternatively, we could remove the readonly attribute from the |document|
property on Window.

Ideally, we'd structure these APIs in such a way that we could eventually expose
them to the web.  In my dream world, a community of people who were interested
in XSLT could use these APIs to implement XSLT just as well as we can in the
engine.

> The above methods are used in Document::applyXSLTransform but not public in
web.

Right, but we should head towards making these APIs public in the web.  We don't
have to make them public in the beginning when we land the first CL, but that
should be our eventual goal.

> My plan is:
> - some part of C++ applyXSLTransform will be re-implemented by using
Javascript,
> - the left C++ applyXSLTransform is moved into XSLTProcessor (private method
for PrivateScript).
> - transformSourceDocument will be re-implemented by using Javascript

I think we should be more ambitious.  Here's a rough outline for another
approach:

A) The engine watches processing directives.  When it detects one that relates
to XSLT, it loads the XSLT script into that document.
B) The engine then exposes a (private) Window#replaceDocument function as well
as the public XSLTProcessor API.

From (A) and (B), we should be able to implement everything else in JavaScript
without any other hooks into or out of the engine.

[tasak, 2014-08-12 09:44:27]

On 2014/08/06 04:12:53, abarth wrote:
> I think we should be more ambitious.  Here's a rough outline for another
> approach:
> 
> A) The engine watches processing directives.  When it detects one that relates
> to XSLT, it loads the XSLT script into that document.
> B) The engine then exposes a (private) Window#replaceDocument function as well
> as the public XSLTProcessor API.
> 
> From (A) and (B), we should be able to implement everything else in JavaScript
> without any other hooks into or out of the engine.

I see.
I will try in the future.

[tasak, 2014-08-13 06:03:47]

Would you review CL?

[abarth-chromium, 2014-08-13 16:10:55]

not lgtm

This CL introduces back doors for private scripts that we would never expose to
normal web pages.  The primary benefit of lifting XSLT into JavaScript is to
make the code play by the same rules as normal web pages.  Introducing these
back doors defeats that benefit.  Instead, we need to use a design that does not
introduce these sorts of back doors.

[tasak, 2014-08-14 01:54:28]

On 2014/08/13 16:10:55, abarth wrote:
> not lgtm
> 
> This CL introduces back doors for private scripts that we would never expose
to
> normal web pages.  The primary benefit of lifting XSLT into JavaScript is to
> make the code play by the same rules as normal web pages.  Introducing these
> back doors defeats that benefit.  Instead, we need to use a design that does
not
> introduce these sorts of back doors.

I would like to confirm the back doors.

I updated ProcessingInstruction.idl and XSLTProcessor.idl. But they are
basically only used for XSLT.
Normal web pages don't use XSLT. So updating the above IDL files doesn't affect
normal web pages, I think.
Is this correct?

So your concern is DocumentXSLT.idl?

[tasak, 2014-08-14 01:58:12]

On 2014/08/14 01:54:28, tasak wrote:
> On 2014/08/13 16:10:55, abarth wrote:
> > not lgtm
> > 
> > This CL introduces back doors for private scripts that we would never expose
> to
> > normal web pages.  The primary benefit of lifting XSLT into JavaScript is to
> > make the code play by the same rules as normal web pages.  Introducing these
> > back doors defeats that benefit.  Instead, we need to use a design that does
> not
> > introduce these sorts of back doors.
> 
> I would like to confirm the back doors.
> 
> I updated ProcessingInstruction.idl and XSLTProcessor.idl. But they are
> basically only used for XSLT.
> Normal web pages don't use XSLT. So updating the above IDL files doesn't
affect
> normal web pages, I think.
> Is this correct?
> 
> So your concern is DocumentXSLT.idl?

I also would like to ask replaceDocument.

Currently only XSLT needs something like replaceDocument, I think.
However, if other technologies don't need replaceDocument, I'm afraid that the
API is too much.

Do you have any idea about some technologies which needs replaceDocument?

[abarth-chromium, 2014-08-14 02:11:14]

On 2014/08/14 at 01:54:28, tasak wrote:
> I updated ProcessingInstruction.idl and XSLTProcessor.idl. But they are
basically only used for XSLT.
> Normal web pages don't use XSLT. So updating the above IDL files doesn't
affect normal web pages, I think.
> Is this correct?

Adding back doors doesn't affect normal web pages.  That isn't the issue.  The
issue is the maintainability of our implementation of XSLT.  There are two
things we could hope to achieve by lifting our implementation of XSLT into
JavaScript:

1) XSLT no longer imposes any additional constraints on the engine because
everything that our implementation of XSLT uses in the engine already exists to
service the rest of the web platform.

2) Web developers can use their own XSLT implementation that works just as well
as ours does because it's able to interact with the engine in exactly the same
way that our implementation does.

Adding back doors (i.e., OnlyExposedToPrivateScript functions) works against
both those goals.

> So your concern is DocumentXSLT.idl?

The starting point for this work is to understand what we would need to add to
the web platform in order to lift our implementation of XSLT into JavaScript
without adding any back doors.  The CL doesn't move us in that direction.

On 2014/08/14 at 01:58:12, tasak wrote:
> Currently only XSLT needs something like replaceDocument, I think.
> However, if other technologies don't need replaceDocument, I'm afraid that the
API is too much.

That last statement doesn't follow from your earlier statements.

> Do you have any idea about some technologies which needs replaceDocument?

It's not required that any other technology needs replaceDocument.  What's
required is that we could imagine (and eventually will) expose replaceDocument
to the web.  That means we'll eventually achieve goals (1) and (2).

[tasak, 2014-08-14 08:18:58]

Thank you for replying.

On 2014/08/14 02:11:14, abarth wrote:

> > Currently only XSLT needs something like replaceDocument, I think.
> > However, if other technologies don't need replaceDocument, I'm afraid that
the
> API is too much.
> 
> That last statement doesn't follow from your earlier statements.

I mean, if I decide to implement replaceDocument, I'm just thinking of whether
the API makes people happy or not.
(e.g. web developers, users, and browser vendors)

> It's not required that any other technology needs replaceDocument.  What's
> required is that we could imagine (and eventually will) expose replaceDocument
> to the web.  That means we'll eventually achieve goals (1) and (2).

I think, I'm not sure if I need to implement replaceDocument right now.
(I mean, after landing this patch, we can replace, because
OnlyExposedToPrivateScript is not public.)

However, I'm now investigating how to implement replaceDocument like API.
I guess, the API would look a little dirty, because blink doesn't allow to
change document's frame after creating.

[haraken, 2014-08-14 09:17:36]

I agree with abarth@ that a back-door API should be a more general one that can
be exposed to the web in the future. In my understanding, the only back-door API
that XSLT-in-JS needs would be replaceDocument (or something like that).

Remember that although DOM attributes/methods with [OnlyExposedToPrivateScript]
are back-door APIs, DOM attributes/methods with [ImplementedInPrivateScript,
OnlyExposedToPrivateScript] are _not_ back-door APIs. DOM attributes/methods
with [ImplementedInPrivateScript, OnlyExposedToPrivateScript] just define APIs
for Blink C++ to call into private scripts.

I drew an illustration about the situation.
https://lh4.googleusercontent.com/0o5ml9SZYz2SbIoFKEhGl_DrQOfOJYxShAozuquSWi2...

- As illustrated, I think that [What tasak's patch does] is a good first step
toward [Ideal world 1].

- That being said, we don't have a concrete plan to move [What tasak's patch
does] forward to [Ideal world 1]. This is because it's a substantial amount of
work to move core/xml/ and libxslt to Blink-in-JS. Also, given that core/xml/
and libxslt are already self-contained, there is no clear benefit in moving
core/xml/ and libxslt to Blink-in-JS.

Given the above, I think that a right way to go would be:

1) Do [What tasak's patch does] now. This has a benefit on Blink because we can
factor out all XSLT-related code from core/ (except core/xml/).

2) Let third parties do [Ideal world 2].

What do you think?

[haraken, 2014-08-14 09:19:40]

On 2014/08/14 09:17:36, haraken wrote:
> I agree with abarth@ that a back-door API should be a more general one that
can
> be exposed to the web in the future. In my understanding, the only back-door
API
> that XSLT-in-JS needs would be replaceDocument (or something like that).
> 
> Remember that although DOM attributes/methods with
[OnlyExposedToPrivateScript]
> are back-door APIs, DOM attributes/methods with [ImplementedInPrivateScript,
> OnlyExposedToPrivateScript] are _not_ back-door APIs. DOM attributes/methods
> with [ImplementedInPrivateScript, OnlyExposedToPrivateScript] just define APIs
> for Blink C++ to call into private scripts.
> 
> I drew an illustration about the situation.
>
https://lh4.googleusercontent.com/0o5ml9SZYz2SbIoFKEhGl_DrQOfOJYxShAozuquSWi2...

Correct URL is here: http://haraken.info/null/xslt_in_js.png

[tasak, 2014-08-14 11:42:00]

On 2014/08/14 08:18:58, tasak wrote:

> However, I'm now investigating how to implement replaceDocument like API.
> I guess, the API would look a little dirty, because blink doesn't allow to
> change document's frame after creating.

I think, I found a solution:

- Window has OnlyExposedToPrivateScript API:
    [OnlyExposedToPrivateScript] void replaceDocument(DOMString contentType,
DOMString documentSource);
- Document has OnlyExposedToPrivateScript API:
    [OnlyExposedToPrivateScript] DOMString souceAsText;
- XSLTProcessor has OnlyExposedToPrivateScript API:
    [OnlyExposedToPrivateScript] void setStylesheet(XSLStyleSheet sheet);

My idea is: it is very difficult to replace current Document with another
Document.
However, if a new Document is given as text string, it is much easier.

The following is a mock explaining what I want to do:

  var processor = new XSLTProcessor;
  processor.setStyleSheet(pi);
  var transformed = processor.transformToDocument(document);
  window.replaceDocument(transformed.contentType, transformed.sourceAsText);

Firstly I tried XMLSerializer. However, it doesn't work well, because it
replaces < in script tag with &lt;. (and also >, &, ...).
So I need Document's sourceAsText. I will share most code with XMLSerializer.

(In the future, I will try to implement sourceAsText in Javascript.)

[abarth-chromium, 2014-08-14 15:39:52]

On 2014/08/14 at 09:17:36, haraken wrote:
> I agree with abarth@ that a back-door API should be a more general one that
can be exposed to the web in the future. In my understanding, the only back-door
API that XSLT-in-JS needs would be replaceDocument (or something like that).
> 
> Remember that although DOM attributes/methods with
[OnlyExposedToPrivateScript] are back-door APIs, DOM attributes/methods with
[ImplementedInPrivateScript, OnlyExposedToPrivateScript] are _not_ back-door
APIs. DOM attributes/methods with [ImplementedInPrivateScript,
OnlyExposedToPrivateScript] just define APIs for Blink C++ to call into private
scripts.

We're going to need some way for C++ to call into JavaScript to kick off the
process.  However, ideally that would be a way that web authors could use in the
future (to address 2).  What's in the CL is too low-level for us to expose it to
authors.  Maybe an appropriate call into JavaScript would be "XSLT Processing
Instruction Available".  Today we'd implement that as a function, but in the
future we could implement that as an event.

> - As illustrated, I think that [What tasak's patch does] is a good first step
toward [Ideal world 1].

Except that we're calling into the private script at times that we don't call
into author JavaScript, which means it can poke the engine at times that normal
scripts can't.

> Given the above, I think that a right way to go would be:
> 
> 1) Do [What tasak's patch does] now. This has a benefit on Blink because we
can factor out all XSLT-related code from core/ (except core/xml/).
> 
> 2) Let third parties do [Ideal world 2].
> 
> What do you think?

I think we need to spend some more time on the design so that we're headed
towards (1) and (2).

On 2014/08/14 at 11:42:00, tasak wrote:
> - Window has OnlyExposedToPrivateScript API:
>     [OnlyExposedToPrivateScript] void replaceDocument(DOMString contentType,
DOMString documentSource);

That seems similar to DOMParser#parseFromString.  We should probably reverse the
order of the arguments to match.  :)

> - Document has OnlyExposedToPrivateScript API:
>     [OnlyExposedToPrivateScript] DOMString souceAsText;

This probably should be called innerHTML to match Element#innerHTML.

> - XSLTProcessor has OnlyExposedToPrivateScript API:
>     [OnlyExposedToPrivateScript] void setStylesheet(XSLStyleSheet sheet);

I don't understand this API.  XSLStyleSheet is not a web-exposed concept as far
as I can tell.  Why isn't XSLTProcessor#importStylesheet sufficient?

> My idea is: it is very difficult to replace current Document with another
Document.
> However, if a new Document is given as text string, it is much easier.

That makes sense.

> The following is a mock explaining what I want to do:
> 
>   var processor = new XSLTProcessor;
>   processor.setStyleSheet(pi);
>   var transformed = processor.transformToDocument(document);
>   window.replaceDocument(transformed.contentType, transformed.sourceAsText);
> 
> Firstly I tried XMLSerializer. However, it doesn't work well, because it
replaces < in script tag with &lt;. (and also >, &, ...).
> So I need Document's sourceAsText. I will share most code with XMLSerializer.

Yeah, we need an HTMLSerializer, which is essentially what innerHTML is...

I was imagining something more like the following:

https://docs.google.com/document/d/1A_Y60n6UC44cmOSFsEoq0sceCMX4R6io_9RG2pDaJ...

In this approach, the script is responsible for loading the stylesheet, etc. 
The private APIs we'd need are:

1) Call onProcessingInstructionAvailable at the end of the microtask when a
ProcessingInstruction is added to the document (e.g., as if there was a
MutationObserver watching for it).
2) Window#replaceDocument.

[haraken, 2014-08-14 15:48:06]

On 2014/08/14 15:39:52, abarth wrote:
> On 2014/08/14 at 09:17:36, haraken wrote:
> > I agree with abarth@ that a back-door API should be a more general one that
> can be exposed to the web in the future. In my understanding, the only
back-door
> API that XSLT-in-JS needs would be replaceDocument (or something like that).
> > 
> > Remember that although DOM attributes/methods with
> [OnlyExposedToPrivateScript] are back-door APIs, DOM attributes/methods with
> [ImplementedInPrivateScript, OnlyExposedToPrivateScript] are _not_ back-door
> APIs. DOM attributes/methods with [ImplementedInPrivateScript,
> OnlyExposedToPrivateScript] just define APIs for Blink C++ to call into
private
> scripts.
> 
> We're going to need some way for C++ to call into JavaScript to kick off the
> process.  However, ideally that would be a way that web authors could use in
the
> future (to address 2).  What's in the CL is too low-level for us to expose it
to
> authors.  Maybe an appropriate call into JavaScript would be "XSLT Processing
> Instruction Available".  Today we'd implement that as a function, but in the
> future we could implement that as an event.
> 
> > - As illustrated, I think that [What tasak's patch does] is a good first
step
> toward [Ideal world 1].
> 
> Except that we're calling into the private script at times that we don't call
> into author JavaScript, which means it can poke the engine at times that
normal
> scripts can't.
> 
> > Given the above, I think that a right way to go would be:
> > 
> > 1) Do [What tasak's patch does] now. This has a benefit on Blink because we
> can factor out all XSLT-related code from core/ (except core/xml/).
> > 
> > 2) Let third parties do [Ideal world 2].
> > 
> > What do you think?
> 
> I think we need to spend some more time on the design so that we're headed
> towards (1) and (2).
> 
> On 2014/08/14 at 11:42:00, tasak wrote:
> > - Window has OnlyExposedToPrivateScript API:
> >     [OnlyExposedToPrivateScript] void replaceDocument(DOMString contentType,
> DOMString documentSource);
> 
> That seems similar to DOMParser#parseFromString.  We should probably reverse
the
> order of the arguments to match.  :)
> 
> > - Document has OnlyExposedToPrivateScript API:
> >     [OnlyExposedToPrivateScript] DOMString souceAsText;
> 
> This probably should be called innerHTML to match Element#innerHTML.
> 
> > - XSLTProcessor has OnlyExposedToPrivateScript API:
> >     [OnlyExposedToPrivateScript] void setStylesheet(XSLStyleSheet sheet);
> 
> I don't understand this API.  XSLStyleSheet is not a web-exposed concept as
far
> as I can tell.  Why isn't XSLTProcessor#importStylesheet sufficient?
> 
> > My idea is: it is very difficult to replace current Document with another
> Document.
> > However, if a new Document is given as text string, it is much easier.
> 
> That makes sense.
> 
> > The following is a mock explaining what I want to do:
> > 
> >   var processor = new XSLTProcessor;
> >   processor.setStyleSheet(pi);
> >   var transformed = processor.transformToDocument(document);
> >   window.replaceDocument(transformed.contentType, transformed.sourceAsText);
> > 
> > Firstly I tried XMLSerializer. However, it doesn't work well, because it
> replaces < in script tag with &lt;. (and also >, &, ...).
> > So I need Document's sourceAsText. I will share most code with
XMLSerializer.
> 
> Yeah, we need an HTMLSerializer, which is essentially what innerHTML is...
> 
> I was imagining something more like the following:
> 
>
https://docs.google.com/document/d/1A_Y60n6UC44cmOSFsEoq0sceCMX4R6io_9RG2pDaJ...
> 
> In this approach, the script is responsible for loading the stylesheet, etc. 
> The private APIs we'd need are:
> 
> 1) Call onProcessingInstructionAvailable at the end of the microtask when a
> ProcessingInstruction is added to the document (e.g., as if there was a
> MutationObserver watching for it).
> 2) Window#replaceDocument.

Thanks Adam for the details. I completely agree with your proposal.

[tasak, 2014-08-14 17:13:05]

Thank you for the document. Now I think, I understand your idea.

On 2014/08/14 15:39:52, abarth wrote:

> On 2014/08/14 at 11:42:00, tasak wrote:
> > - Window has OnlyExposedToPrivateScript API:
> >     [OnlyExposedToPrivateScript] void replaceDocument(DOMString contentType,
> DOMString documentSource);
> 
> That seems similar to DOMParser#parseFromString.  We should probably reverse
the
> order of the arguments to match.  :)

Yes, this is very similar to parseFromString.
I see. I will change the arguments order.

> This probably should be called innerHTML to match Element#innerHTML.

So I need to explain why not innerHTML.

As far as I investigate, transformToDocument can create SVGDocument, XMLDocument
and HTMLDocument. So XMLDocument and SVGDocument probably need innerXML?

I guess, we need innerXMLorHTML or something.

> > - XSLTProcessor has OnlyExposedToPrivateScript API:
> >     [OnlyExposedToPrivateScript] void setStylesheet(XSLStyleSheet sheet);
> 
> I don't understand this API.  XSLStyleSheet is not a web-exposed concept as
far
> as I can tell.  Why isn't XSLTProcessor#importStylesheet sufficient?

Yeah, I tried importStyleSheet and found that importStyleSheet requires a root
node of a XSLStyleSheet. c.f.
https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_JavaScript_interfa...

So I found the following:
- We have processing instructions.
- We can obtain sheets from processing instructions. 
- We want to provide processing instructions or sheets(i.e. XSLStyleSheets) for
XSLTProcessor.

- XSLTProcessor has importStyleSheet API.
- The API requires a root node of XSLStyleSheet, i.e. inside sheets.
- We have no public API to obtain any DOM nodes in XSLStyleSheet.

... currently I have no good idea about fixing setStylesheet/importStylesheet
issue.

(idea 1): add a new API (to obtain DOM node in XSLStyleSheet) to
ProcessingInstruction or XSLStyleSheet, and use importStylesheet.

(idea 2): add a new API: setStylesheet to XSLTProcessor, and just use the API.

(idea 3): add a new API to obtain inner XML text from XSLStyleSheet /
ProcessingInstruction, parse the XML text and use importStylesheet.

I wrote (idea 2). However I have no strong reason. I just thought, it is the
easiest way, because current Blink implementation has setStylesheet C++ code.

> I was imagining something more like the following:
> 
>
https://docs.google.com/document/d/1A_Y60n6UC44cmOSFsEoq0sceCMX4R6io_9RG2pDaJ...

... I see. Currently resource fetcher obtains XSLStyleSheet. Instead, we can use
XMLHttpRequest to obtain XSLStyleSheet.

I love this approach, because we can see XSLStyleSheet and know DOM nodes in
XSLStyleSheet.
So we can use importStylesheet. We don't need setStylesheet.

> In this approach, the script is responsible for loading the stylesheet, etc. 
> The private APIs we'd need are:
> 
> 1) Call onProcessingInstructionAvailable at the end of the microtask when a
> ProcessingInstruction is added to the document (e.g., as if there was a
> MutationObserver watching for it).

Yeah, we need to know "ProcessingInstruction is inserted into document" and
"ProcessingInstruction is removed from document".

> 2) Window#replaceDocument.

[abarth-chromium, 2014-08-14 20:41:07]

On 2014/08/14 at 17:13:05, tasak wrote:
> > This probably should be called innerHTML to match Element#innerHTML.
> 
> So I need to explain why not innerHTML.
> 
> As far as I investigate, transformToDocument can create SVGDocument,
XMLDocument and HTMLDocument. So XMLDocument and SVGDocument probably need
innerXML?
> 
> I guess, we need innerXMLorHTML or something.

innerHTML should already know how to handle XML.

> > > - XSLTProcessor has OnlyExposedToPrivateScript API:
> > >     [OnlyExposedToPrivateScript] void setStylesheet(XSLStyleSheet sheet);
> > 
> > I don't understand this API.  XSLStyleSheet is not a web-exposed concept as
far
> > as I can tell.  Why isn't XSLTProcessor#importStylesheet sufficient?
> 
> Yeah, I tried importStyleSheet and found that importStyleSheet requires a root
node of a XSLStyleSheet. c.f.
https://developer.mozilla.org/en-US/docs/Using_the_Mozilla_JavaScript_interfa...
> 
> So I found the following:
> - We have processing instructions.
> - We can obtain sheets from processing instructions. 
> - We want to provide processing instructions or sheets(i.e. XSLStyleSheets)
for XSLTProcessor.
> 
> - XSLTProcessor has importStyleSheet API.
> - The API requires a root node of XSLStyleSheet, i.e. inside sheets.
> - We have no public API to obtain any DOM nodes in XSLStyleSheet.
> 
> ... currently I have no good idea about fixing setStylesheet/importStylesheet
issue.

In my doc, I show how to solve this problem.  Basically, the JavaScript fetches
the XSL directly from the server and asks for the response in the form of a
document.  Then you have direct access to the root node of the style sheet.

> ... I see. Currently resource fetcher obtains XSLStyleSheet. Instead, we can
use XMLHttpRequest to obtain XSLStyleSheet.

Exactly.

> I love this approach, because we can see XSLStyleSheet and know DOM nodes in
XSLStyleSheet.
> So we can use importStylesheet. We don't need setStylesheet.

Yep!

> Yeah, we need to know "ProcessingInstruction is inserted into document" and
"ProcessingInstruction is removed from document".

We only need "ProcessingInstruction is inserted into document".  The script can
create a MutationObserver to detect when the node is removed from the document
itself.

[tasak, 2014-08-14 23:02:16]

On 2014/08/14 20:41:07, abarth wrote:

> innerHTML should already know how to handle XML.

I see. I will use innerHTML.

> We only need "ProcessingInstruction is inserted into document".  The script
can
> create a MutationObserver to detect when the node is removed from the document
> itself.

I got an idea:

- In ProcessingInstruction::insertedInto, we need only "installClass" (for
PrivateScript) and
  document.addEventListener(DOMContentLoaded, applyTransform).
 
- In applyTransform, all ProcessingInstructions are available. We will traverse
a DOM tree, i.e.
  for (var node = document.firstChild; node; node = node.nextSibling) {
     if (node.nodeName == 'xml-stylesheet') {
        // since we have no node.getAttribute, we will serialize the node and
check by using
        // regexp.
        // we need "type=" and "href=".
        if (type == "text/xml" || type == "text/xsl" || type ==
"application/xml" || type == "application/xhtml+xml" || type ==
"application/rss+xml" || type == "application/atom+xml")
            // invoke onProcessingInstructionAvailable for the node.
     }
  }

[abarth-chromium, 2014-08-14 23:05:29]

On 2014/08/14 at 23:02:16, tasak wrote:
> I got an idea:
> 
> - In ProcessingInstruction::insertedInto, we need only "installClass" (for
PrivateScript) and
>   document.addEventListener(DOMContentLoaded, applyTransform).
>  
> - In applyTransform, all ProcessingInstructions are available. We will
traverse a DOM tree, i.e.
>   for (var node = document.firstChild; node; node = node.nextSibling) {
>      if (node.nodeName == 'xml-stylesheet') {
>         // since we have no node.getAttribute, we will serialize the node and
check by using
>         // regexp.
>         // we need "type=" and "href=".
>         if (type == "text/xml" || type == "text/xsl" || type ==
"application/xml" || type == "application/xhtml+xml" || type ==
"application/rss+xml" || type == "application/atom+xml")
>             // invoke onProcessingInstructionAvailable for the node.
>      }
>   }

Yeah, that should work.  It means we don't get to overlap retrieving the
document and the style sheet from the network, but I think that's a fine place
to start.

[tasak, 2014-08-14 23:07:34]

On 2014/08/14 23:02:16, tasak wrote:

>         // since we have no node.getAttribute, we will serialize the node and
> check by using
>         // regexp.
>         // we need "type=" and "href=".

Or invoke PrivateScript in ProcessingInstruction::insertedInto to set this.type_
and this.href_:

   ProcessingInstructionPrototype.setHref = function(href) {
      this.href_ = href;
   }
   ProcessingInstructionPrototype.setType = function(type) { // or setIsXsl?
      this.type_ = type;
   }

[tasak, 2014-08-14 23:08:14]

On 2014/08/14 23:05:29, abarth wrote:
> On 2014/08/14 at 23:02:16, tasak wrote:
> > I got an idea:
> > 
> > - In ProcessingInstruction::insertedInto, we need only "installClass" (for
> PrivateScript) and
> >   document.addEventListener(DOMContentLoaded, applyTransform).
> >  
> > - In applyTransform, all ProcessingInstructions are available. We will
> traverse a DOM tree, i.e.
> >   for (var node = document.firstChild; node; node = node.nextSibling) {
> >      if (node.nodeName == 'xml-stylesheet') {
> >         // since we have no node.getAttribute, we will serialize the node
and
> check by using
> >         // regexp.
> >         // we need "type=" and "href=".
> >         if (type == "text/xml" || type == "text/xsl" || type ==
> "application/xml" || type == "application/xhtml+xml" || type ==
> "application/rss+xml" || type == "application/atom+xml")
> >             // invoke onProcessingInstructionAvailable for the node.
> >      }
> >   }
> 
> Yeah, that should work.  It means we don't get to overlap retrieving the
> document and the style sheet from the network, but I think that's a fine place
> to start.

I see.
Thank you.

[abarth-chromium, 2014-08-14 23:48:05]

On 2014/08/14 at 23:07:34, tasak wrote:
> Or invoke PrivateScript in ProcessingInstruction::insertedInto to set
this.type_ and this.href_:

Please do not add back doors.

[tasak, 2014-08-27 11:12:31]

Would you give me advice to solve XHR problem?

I implemented a prototype (patchset 5) and found one critical problem:
fast/xsl/xslt-second-level-import.xml's regression.

The test has 2 xsl-stylesheets and 1 dtd, i.e. xslt-second-level-import.xsl,
xslt-second-level-import2.xsl and xslt-second-level-import.xsl.dtd.

- xslt-second-level-import.xml imports xslt-second-level-import.xsl.
- xslt-second-level-import.xsl imports xslt-second-level-import2.xsl and
xslt-second-level-import.xsl.dtd.

The problem is that XHR.responseXML is null when we obtain
xslt-second-level-import.xsl by using XHR, because XHR doesn't solve
xslt-second-level-import.xsl.dtd's import.

So XHR says that xslt-second-level-import.xsl is not well-formed. This causes
XHR.resonseXML null. Looking at XHR spec, this behavior is valid. I think, we
should not change this behavior.

If we manually parse XHR.responseText, we cannot change the URL of the parsed
document (so the document's URL is empty). This makes it impossible for us to
obtain xslt-second-level-import2.xsl.

I don't have any good idea for solving this problem. My idea is:

(solution a) adding a backdoor to XHR to obtain not-well-formed responseXML,

(solution b) adding an option to make XHR to see external DTD, and

(solution c) adding a backdoor to update document's URL.

The all above solutions look bad... Especially (c) causes high security risk
even if the backdoor is only for private script.

I really need your advice.

[tasak, 2014-08-28 10:56:15]

I found another idea.
The idea requires adding one backdoor to XSLStyleSheet to obtain stylesheet root
node, i.e.

- ProcessingInstruction code creates XSLStyleSheet (we don't use
XMLHttpRequest).

- In ProcessingInstruction's sheetLoaded, invoke
onProcessingInstructionAvailable method implemented in PrivateScript.
  ProcessingInstruction cpp code should provide its stylesheet root node for
onProcessingInstructionAvailable, i.e.

  ...onProcessingInstructionAvailable = function(styleSheetRootNode) {
      ...
      var processor = new XSLTProcessor;
      processor.importStylesheet(styleSheetRootNode);
      var newDoc = processor.transformToDocument(document);
      var content = HTMLSerializer().serializeToString(newDoc);
      window.replaceDocument(content);
 ....
  }

I will implement this idea.

[tasak, 2014-08-28 11:04:21]

On 2014/08/28 10:56:15, tasak wrote:
> I found another idea.
> The idea requires adding one backdoor to XSLStyleSheet to obtain stylesheet
root
> node, i.e.

Or creating a hidden frame to obtain xsl-stylesheet. I will also try this frame
idea.

[abarth-chromium, 2014-09-02 19:36:46]

On 2014/08/27 at 11:12:31, tasak wrote:
> I don't have any good idea for solving this problem. My idea is:
> 
> (solution a) adding a backdoor to XHR to obtain not-well-formed responseXML,
> (solution b) adding an option to make XHR to see external DTD, and
> (solution c) adding a backdoor to update document's URL.
> 
> The all above solutions look bad... Especially (c) causes high security risk
even if the backdoor is only for private script.
> 
> I really need your advice.

I'd recommend simply not supporting this feature.  If the XSL isn't well-formed,
then ignore it.

[tasak, 2014-09-03 02:10:10]

On 2014/09/02 19:36:46, abarth wrote:
> On 2014/08/27 at 11:12:31, tasak wrote:
> > I don't have any good idea for solving this problem. My idea is:
> > 
> > (solution a) adding a backdoor to XHR to obtain not-well-formed responseXML,
> > (solution b) adding an option to make XHR to see external DTD, and
> > (solution c) adding a backdoor to update document's URL.
> > 
> > The all above solutions look bad... Especially (c) causes high security risk
> even if the backdoor is only for private script.
> > 
> > I really need your advice.
> 
> I'd recommend simply not supporting this feature.  If the XSL isn't
well-formed,
> then ignore it.

This is my mistake. LayoutTests/fast/xsl/xslt-second-level-import.xml includes a
valid xsl-stylesheet, i.e.
LayoutTests/fast/xsl/resources/xslt-second-level-import.xsl.
The stylesheet includes an external dtd, i.e.
LayoutTests/fast/xsl/resources/xslt-second-level-import.xsl.dtd.

XMLHttpRequest cannot solve the external dtd and says that the stylesheet is not
well-formed.

I think, we probably need to support external dtd.

I wrote document about this:
https://docs.google.com/a/google.com/document/d/15rNBNb2-wXxuRNWNTAEFu1Nj20vg...

[abarth-chromium, 2014-09-03 04:59:36]

On 2014/09/03 at 02:10:10, tasak wrote:
> I think, we probably need to support external dtd.

Why is that?

[tasak, 2014-09-03 05:06:44]

On 2014/09/03 04:59:36, abarth wrote:
> On 2014/09/03 at 02:10:10, tasak wrote:
> > I think, we probably need to support external dtd.
> 
> Why is that?

Because we will change shipped behavior if we don't support.

[abarth-chromium, 2014-09-03 05:11:05]

On 2014/09/03 at 05:06:44, tasak wrote:
> Because we will change shipped behavior if we don't support.

I'm ok with that.  At one point in this process, we were considering dropping
the feature entirely, which would be a larger change to our shipping behavior.

[tasak, 2014-09-03 05:33:26]

On 2014/09/03 05:11:05, abarth wrote:
> On 2014/09/03 at 05:06:44, tasak wrote:
> > Because we will change shipped behavior if we don't support.
> 
> I'm ok with that.  At one point in this process, we were considering dropping
> the feature entirely, which would be a larger change to our shipping behavior.

I see. However, we have no data about how many people use external DTD in
xml-stylesheet.

So I think, we have two options:

(1) Add UseCounter. Wait until we have enough data about # of external DTD
users.

(2) Add UseCounter and also implement "setStylesheet". Wait until we have enough
data.

In both case, when we have the data, we will discuss whether it is possible to
deprecate external dtd or not.

- if possible to deprecate, 

  (1) replace XSLT with PrivateScript which uses XMLHttpRequest and
importStylesheet,

  (2) remove setStylesheet. Instead, reimplement XSLT by using XMLHttpRequest
and importStylesheet.

- if not possible,

  (1) ... I'm not sure. Implement setStylesheet?

  (2) Keep setStylesheet?

  In both (1) and (2), keep to see UseCounter. When # of external dtd users
becomes very small, we will quickly deprecate external dtd.

I would like to ask which is better solution, (1) or (2).

[abarth-chromium, 2014-09-03 05:40:28]

IMHO, we should implement XSLT using XMLHttpRequest behind a runtime flag and
add a use counter.  In all likelihood, we will be able to ship the
XMLHttpRequest version.  If the use counter indicates that we cannot, we can
remove the JavaScript implementation and leave the C++ implementation.

[tasak, 2014-09-03 05:48:30]

On 2014/09/03 05:40:28, abarth wrote:
> IMHO, we should implement XSLT using XMLHttpRequest behind a runtime flag and
> add a use counter.  In all likelihood, we will be able to ship the
> XMLHttpRequest version.  If the use counter indicates that we cannot, we can
> remove the JavaScript implementation and leave the C++ implementation.

I see. I will execute this plan.

[tasak, 2014-09-08 05:15:27]

On 2014/09/03 05:48:30, tasak wrote:
> On 2014/09/03 05:40:28, abarth wrote:
> > IMHO, we should implement XSLT using XMLHttpRequest behind a runtime flag
and
> > add a use counter.  In all likelihood, we will be able to ship the
> > XMLHttpRequest version.  If the use counter indicates that we cannot, we can
> > remove the JavaScript implementation and leave the C++ implementation.
> 
> I see. I will execute this plan.

Since we are trying to deprecate external DTD in XSL stylesheet, we cannot clean
up StyleEngine and Document's code used by XSLT.
(If we add setStylesheet, we can clean up, because it doesn't break backward
compatibility. My plan is firstly "setStylesheet", next importStylesheet. But I
guess, it is not allowable.)

So I will close this CL at this moment.

After we have enough data about external DTD, I will retry this issue.

[haraken, 2014-09-08 07:58:09]

On 2014/09/08 05:15:27, tasak wrote:
> On 2014/09/03 05:48:30, tasak wrote:
> > On 2014/09/03 05:40:28, abarth wrote:
> > > IMHO, we should implement XSLT using XMLHttpRequest behind a runtime flag
> and
> > > add a use counter.  In all likelihood, we will be able to ship the
> > > XMLHttpRequest version.  If the use counter indicates that we cannot, we
can
> > > remove the JavaScript implementation and leave the C++ implementation.
> > 
> > I see. I will execute this plan.
> 
> Since we are trying to deprecate external DTD in XSL stylesheet, we cannot
clean
> up StyleEngine and Document's code used by XSLT.
> (If we add setStylesheet, we can clean up, because it doesn't break backward
> compatibility. My plan is firstly "setStylesheet", next importStylesheet. But
I
> guess, it is not allowable.)
> 
> So I will close this CL at this moment.
> 
> After we have enough data about external DTD, I will retry this issue.

I don't think it's reasonable to block this work until we get enough UseCounter
data for the external DTD. Alternately, we can:

- Add a private API for setStyleSheet() and move XSLT to JS.
- Add use counters for the external DTD.
- If the use counters are low enough, we remove the support for the external DTD
and remove the setStyleSheet().

I agree that we should try hard not to introduce private APIs, but it won't make
much sense to block the work by the strict restriction about private APIs
(Private APIs are just private APIs, which are not yet exposed to the web).

I think it would be better to proceed with the work of XSLT-in-JS with
setStyleSheet() and iterate from there (than just to suspend the work until we
get enough UseCounter data). I believe it will give us a shorter path to the
goal that XSLT-in-JS has no private API and can be developed by third parties.

What do you think?

[haraken, 2014-09-09 01:32:52]

On 2014/09/08 07:58:09, haraken wrote:
> On 2014/09/08 05:15:27, tasak wrote:
> > On 2014/09/03 05:48:30, tasak wrote:
> > > On 2014/09/03 05:40:28, abarth wrote:
> > > > IMHO, we should implement XSLT using XMLHttpRequest behind a runtime
flag
> > and
> > > > add a use counter.  In all likelihood, we will be able to ship the
> > > > XMLHttpRequest version.  If the use counter indicates that we cannot, we
> can
> > > > remove the JavaScript implementation and leave the C++ implementation.
> > > 
> > > I see. I will execute this plan.
> > 
> > Since we are trying to deprecate external DTD in XSL stylesheet, we cannot
> clean
> > up StyleEngine and Document's code used by XSLT.
> > (If we add setStylesheet, we can clean up, because it doesn't break backward
> > compatibility. My plan is firstly "setStylesheet", next importStylesheet.
But
> I
> > guess, it is not allowable.)
> > 
> > So I will close this CL at this moment.
> > 
> > After we have enough data about external DTD, I will retry this issue.
> 
> I don't think it's reasonable to block this work until we get enough
UseCounter
> data for the external DTD. Alternately, we can:
> 
> - Add a private API for setStyleSheet() and move XSLT to JS.
> - Add use counters for the external DTD.
> - If the use counters are low enough, we remove the support for the external
DTD
> and remove the setStyleSheet().
> 
> I agree that we should try hard not to introduce private APIs, but it won't
make
> much sense to block the work by the strict restriction about private APIs
> (Private APIs are just private APIs, which are not yet exposed to the web).
> 
> I think it would be better to proceed with the work of XSLT-in-JS with
> setStyleSheet() and iterate from there (than just to suspend the work until we
> get enough UseCounter data). I believe it will give us a shorter path to the
> goal that XSLT-in-JS has no private API and can be developed by third parties.
> 
> What do you think?

abarth@: I'd be happy if you have any idea on ^^^ when you have a cycle.