Re: IE Team's Feedback on the XHR Draft

Hi Sunava,

Thanks for your feedback. I had a couple of additional comments on top 
of the ones Anne had.

> On Thu, 07 Feb 2008 02:57:50 +0100, Sunava Dutta 
> <sunavad@windows.microsoft.com> wrote:
>> o   This spec is very different from existing HTML/CSS/DOM spec where 
>> the functionality/API specification is the focus.  This spec talks 
>> about interface specification as well as a lot of details that appear 
>> to be internal implementation issues that cannot be verified by Web 
>> developers.
> 
> I don't think that's true, actually. In fact, the specification leaves 
> implementation details up to the implementation. It says so in the 
> conformance criteria.

So one thing to note is that the implementation doesn't need to keep 
exactly the same flags, references, states etc as the ones talked about 
in the spec. As long as it to any user behaves as if it did.

So for example in the mozilla implementation we don't have the send() 
flag, instead we have one additional main state for the object. I.e. we 
have 6 states, including OPENED_BUT_NOT_SENT and OPENED_BUT_SENT.

To the outside world this is not noticeable since the getter for the 
readyState property returns 1 for both those states.

Maybe we need to point out at the top of the specification something to 
the effect of "the implemenatation doesn't need to use the same 
algorithms or use the same states as the ones described in this 
specification. As long as it to any user of the interface yields the 
same results as if it had".

>> Having internal implementation recommendation for UA's is nice, 
>> however we can improve the readability by calling out implementation 
>> detail sections or having a separate section for this detail .  What 
>> we've love is to have the spec clearly state what is external API 
>> specification, and what is internal implementation details. This way a 
>> web developer can read this without reading the whole spec and take 
>> away the key points.
> 
> I think everything that is not important is not there. So I don't really 
> see the issue.

I think the request here is to use language like "if the opened method 
has been called, but the send method has not then do X" rather than "if 
we're in the OPENED state with the send() flag set to false then do X".

Is that correct?

The problem with that is that it's hard to get that unambigious and 
correct. For example the first wording above is wrong since open might 
have been called, but abort had later been called, and so we should 
behave as if open had not been called.

Or I might just be misunderstanding you :)

>> o   Is this included due to security concerns?
>>
>> ยง  Scripts in the resulting document tree will not be executed, 
>> resources referenced will not be loaded and no associated XSLT will be 
>> applied.
> 
> It's included to get consistent behavior.

Right, I don't think any current implementation applies XSLT 
stylesheets. Additionally, loading resources, such as images and 
stylesheets, pointed to by the document would largely be a waste of 
network traffic as they won't be displayed anyway.

We've had cases where people load XSLT stylesheets using XHR and then 
use javascript to dynamically apply these stylesheets to documents. XSLT 
stylesheets can contain markup like:

<xsl:for-each select="images/image">
   <html:img src="/static/images/{@src}">
</xsl:for-each>

In this case it would be clearly undesirable if the loading the XSLT 
stylesheet using XHR would attempt to load the resource 
"/static/image/{@src}" from the server.

Hope that helps?

Actually, the spec should probably also say that stylesheets should not 
be applied. This is needed since the stylesheet might be inline and thus 
not stopped by the "don't load resources" rule.

Anne, should that be added to the draft?

/ Jonas

Received on Friday, 8 February 2008 21:17:00 UTC