Nabble - w3.org - public-webapi

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-18T21:48:10Z

On Wed, 18 Jun 2008, Zhenbin Xu wrote:
>
> In the case there isn't clear technical differences, I don't think we
> should pick the right solution based on implementer's cost. Rather We
> should base it on customer impact. A bank with 6000 applications built
> on top of IE's current APIs simply would not be happy if some
> applications cannot run due to changes in some underlying object model.
> And this is not IE's problem alone since the bank simply cannot upgrade
> or change the browser, if all other browsers result in the same
> breakage.

For non-Web HTML pages like in this example, solutions like IE's "IE7
mode" are fine. IMHO we should be concentrating on pages on the Web, not
on browser-specific pages -- interoperability isn't relevant when the
page isn't intended to run on multiple browsers.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-18T18:30:47Z

It seems we are in agreement, mostly :-)

The point of a fictional browser is that it has no market share, no application
built on top of it and thus would not cause customer pain when it changes implementation.

In the case there isn't clear technical differences, I don't think we should pick
the right solution based on implementer's cost. Rather We should base it on customer impact.
A bank with 6000 applications built on top of IE's current APIs simply would not be happy
if some applications cannot run due to changes in some underlying object model.
And this is not IE's problem alone since the bank simply cannot upgrade or change the browser,
if all other browsers result in the same breakage.

> -----Original Message-----
> From: Ian Hickson [mailto:ian@...]
> Sent: Tuesday, June 17, 2008 1:51 AM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> webapps@...
> Subject: RE: <Further LC Followup from IE> RE: Potential bugs
> identified in XHR LC Test Suite
>
> On Tue, 17 Jun 2008, Zhenbin Xu wrote:
> > > >
> > > > I am not sure if I understand your question.
> responseXML.parseError
> > > > has the error information
> > > > http://msdn.microsoft.com/en-us/library/aa926483.aspx
> > >
> > > Oh, I assumed Sunava meant a conforming Document object was
> returned.
> > > A parseError-type object would be what I had in mind, yes. However,
> if
> > > we do this, then we should specify it. If we don't specify it, I'd
> > > rather have an exception.
> >
> > The spec can simply state that a conforming document object is
> returned,
> > which includes out-of-band error information. This is what IE does
> today
> > and is a very reasonable approach that allows rich error information
> for
> > debugging.
>
> I don't believe it is conforming for Document objects to have
> parseError
> attributes, but I could be mistaken -- is there a spec for parseError?
> Even if there isn't, though, I agree that it is a generally good
> solution
> to the problem, I'm just saying that we should specify it, so that UAs
> can be standards-compliant and support it interoperably.
>
>
> > > Not really; if the script is expecting an exception, and receives
> null
> > > instead, then they'll just get an exception as soon as they
> > > dereference the object, which in almost all cases will be straight
> > > away.
> >
> > [Zhenbin] I should explain the scenario I talked about. For instance,
> if
> > I am to write a wrapper object myXHR, it makes a difference for me
> when
> > I do the following
> >
> > myXHR.responseXML
> > if (!_innerResponseXML)
> > {
> > try
> > {
> > _innerResponseXML = _innerXHR.responseXML;
> > }
> > catch (e)
> > {
> > _myexception = e;
> > return _dummpyResponseXML;
> > }
> > }
> > return _innerResponseXML;
> >
> > My try catch would not catch null. And the exception would be passed
> on
> > to my callers, which is not what I wanted.
>
> Indeed.
>
>
> > > > If we are going to spec it to accommodate all existing browsers,
> we
> > > > would want to make it "return null or INVALID_STATE_ERR
> exception".
> > >
> > > We want interoperable behaviour, so defining it in this way would
> be a
> > > bad idea. (I don't really have an opinion either way about
> exception
> > > vs null, but it seems that we should just pick whatever is most
> > > commonly implemented, which I'm guessing is what Anne did here.)
> >
> > Fair enough. So let's pick one.
> >
> > What is "commonly implemented"? Is it largest browser market share?
>
> Since the cost to implementations for fixing the problem is independent
> of
> the size of the user base, it would be based just on the number of
> independent implementations.
>
>
> > Is it number of enterprise applications written on top of particular
> > browser?
>
> All the browsers want to be compatible with the Web, so if there are
> mroe
> Web sites depending on the exception behaviour than the null behaviour,
> then we clearly should do the exception behaviour. And vice versa. Do
> we
> have any good numbers on this? (That there are widely deployed browsers
> that return null instead of throwing an exception tends to suggest that
> Web pages don't depend on either behaviour; we'd probably need evidence
> to the contrary to decide one way or the other based on compatibility.)
>
>
> > Is it the number of browers, in which case I hope my fictional
> > home grown personal browser gets a vote :-)
>
> Obviously fictional browsers aren't relevant, since the cost of fixing
> a
> fictional browser is zero.
>
>
> > From a pure technical point of view, predictably throw exception on
> > state violations is easier to understand. I hope you would agree
> there
> > is value to change spec for the sake of consistent programming model
> > (which happens to be the IE model).
>
> Indeed.
>
>
> > Did the spec call out that responseXML returned from XHR should have
> > equivalent DOM support as UA's object? If it is, that would be a
> good
> > topic for us to debate about.
>
> I believe the spec just says that you return a Document object; it is
> the
> lack of a distinction between different Document objects that requires
> the
> level of support to be the same. As you said, a consistent programming
> model has value.
>
>
> > I disagree that because DOM Level 3 is 3+ yr old spec that every UA
> has
> > to support it in order to be XHR compliant, if that is what you
> implied.
>
> I didn't mean to imply that. I don't think XHR should require any
> particular level of support.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``.
> fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._
> ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-
> .;.'

Re: IRI support in XHR, was: XHR LC comments

2008-06-18T07:56:23Z

On Jun 18, 2008, at 1:56 PM, Anne van Kesteren wrote:

> I failed adding a non-ASCII file name through subversion to
> tc.labs.opera.com so I guess that has to wait until we move the test
> suite somewhere else. (I tested IRC support somewhere else.)

Here is a similar test we have in WebKit, and which doesn't need files
with non-ASCII file names: <http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/utf8-path.html
>, <http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/uri/intercept/.htaccess
>.

- WBR, Alexey Proskuryakov

Re: IRI support in XHR, was: XHR LC comments

2008-06-18T03:02:58Z

Anne van Kesteren wrote:
>> I was mentioning it because MS apparently *does* run the test suite,
>> so adding a test would help ensure the problem appears on their radar.
>
> I failed adding a non-ASCII file name through subversion to
> tc.labs.opera.com so I guess that has to wait until we move the test
> suite somewhere else. (I tested IRC support somewhere else.)

In my test (with Apache) I didn't even create the file. I get 404 when
invoking GET on a properly encoded IRI, a 403 when the URL on the wire
was malformed (as for IE). Maybe that's sufficient for a test.

BR, Julian

Re: IRI support in XHR, was: XHR LC comments

2008-06-18T02:56:30Z

On Wed, 18 Jun 2008 11:51:15 +0200, Julian Reschke <julian.reschke@...>
wrote:
> Do you really believe anybody is going to use IRIs in XHR if there's no
> way to make it work in IE?

3/4 means it's not a Web compatibility problem to support them. No idea
what authors will do in the near future.

>>> ...so this should probably be covered by the test suite...
>> Of course, everything should.
>
> I was mentioning it because MS apparently *does* run the test suite, so
> adding a test would help ensure the problem appears on their radar.

I failed adding a non-ASCII file name through subversion to
tc.labs.opera.com so I guess that has to wait until we move the test suite
somewhere else. (I tested IRC support somewhere else.)

--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Re: IRI support in XHR, was: XHR LC comments

2008-06-18T02:51:15Z

Anne van Kesteren wrote:

>
> On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke
> <julian.reschke@...> wrote:
>> Julian Reschke wrote:
>>> That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
>>> work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't
>>> have any kind of interoperability here.
>
> 3/4 doing the same sounds like interoperability is pretty good. There
> are features discovered where there's 6/4 having different behavior.
> (Different versions of the same engine.)

Of course 3/4 sounds better than "less than half of the browsers in use"
:-).

Do you really believe anybody is going to use IRIs in XHR if there's no
way to make it work in IE?

>> ...so this should probably be covered by the test suite...
>
> Of course, everything should.

I was mentioning it because MS apparently *does* run the test suite, so
adding a test would help ensure the problem appears on their radar.

BR, Julian

Re: IRI support in XHR, was: XHR LC comments

2008-06-18T02:40:16Z

On Wed, 18 Jun 2008 11:35:57 +0200, Julian Reschke <julian.reschke@...>
wrote:
> Julian Reschke wrote:
>> That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
>> work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't
>> have any kind of interoperability here.

3/4 doing the same sounds like interoperability is pretty good. There are
features discovered where there's 6/4 having different behavior.
(Different versions of the same engine.)

> ...so this should probably be covered by the test suite...

Of course, everything should.

--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

IRI support in XHR, was: XHR LC comments

2008-06-18T02:35:57Z

Julian Reschke wrote:
> That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
> work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have
> any kind of interoperability here.

...so this should probably be covered by the test suite...

BR, Julian

Re: XHR LC comments

2008-06-18T02:35:12Z

Anne van Kesteren wrote:
>> - If the URL parameter can be a IRI, then somewhere later on we need
>> to state that it needs to be transformed to a URI before it's put on
>> the wire.
>
> Added a transformation step as per 3.1 and also required throwing a
> SYNTAX_ERR in case of failure (ToASCII operation failure seems the most
> likely).

OK, it would probably make sense then to rename the URL parameter and
"stored URL" accordingly, so that it becomes clear that IRIs are allowed.

That being said, I just tested IRIs with IE/FF/Opera/Safari, and they
work everywhere except in IE (both 7 and 8beta) (*). Thus, we don't have
any kind of interoperability here.

BR, Julian

(*) For the non-ASCII characters in the IRI (reference) "/äöü.html", IE
sends the raw (ISO8859-1) encoded bytes.

Re: RE: Potential bugs identified in XHR LC Test Suite

2008-06-17T09:40:02Z

Ian Hickson wrote:

> On Tue, 17 Jun 2008, Zhenbin Xu wrote:
>>>> I am not sure if I understand your question. responseXML.parseError
>>>> has the error information
>>>> http://msdn.microsoft.com/en-us/library/aa926483.aspx
>>> Oh, I assumed Sunava meant a conforming Document object was returned.
>>> A parseError-type object would be what I had in mind, yes. However, if
>>> we do this, then we should specify it. If we don't specify it, I'd
>>> rather have an exception.
>> The spec can simply state that a conforming document object is returned,
>> which includes out-of-band error information. This is what IE does today
>> and is a very reasonable approach that allows rich error information for
>> debugging.
>
> I don't believe it is conforming for Document objects to have parseError
> attributes, but I could be mistaken -- is there a spec for parseError?
> Even if there isn't, though, I agree that it is a generally good solution
> to the problem, I'm just saying that we should specify it, so that UAs
> can be standards-compliant and support it interoperably.

I think we have two choices for how to handle parse errors here:

1. Mandate that a Document object containing a .parseError property
is returned for .responseXML
2. Mandate that null is returned

I think some hodgepodge solution of the two is likely just going to be
harder to code against for developers.

Are we comfortable adding the .parseError object to the XHR spec? Feels
like spec creep to me unfortunately.

/ Jonas

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-17T01:51:02Z

On Tue, 17 Jun 2008, Zhenbin Xu wrote:

> > >
> > > I am not sure if I understand your question. responseXML.parseError
> > > has the error information
> > > http://msdn.microsoft.com/en-us/library/aa926483.aspx
> >
> > Oh, I assumed Sunava meant a conforming Document object was returned.
> > A parseError-type object would be what I had in mind, yes. However, if
> > we do this, then we should specify it. If we don't specify it, I'd
> > rather have an exception.
>
> The spec can simply state that a conforming document object is returned,
> which includes out-of-band error information. This is what IE does today
> and is a very reasonable approach that allows rich error information for
> debugging.

I don't believe it is conforming for Document objects to have parseError
attributes, but I could be mistaken -- is there a spec for parseError?
Even if there isn't, though, I agree that it is a generally good solution
to the problem, I'm just saying that we should specify it, so that UAs
can be standards-compliant and support it interoperably.

> > Not really; if the script is expecting an exception, and receives null
> > instead, then they'll just get an exception as soon as they
> > dereference the object, which in almost all cases will be straight
> > away.
>
> [Zhenbin] I should explain the scenario I talked about. For instance, if
> I am to write a wrapper object myXHR, it makes a difference for me when
> I do the following
>
> myXHR.responseXML
> if (!_innerResponseXML)
> {
> try
> {
> _innerResponseXML = _innerXHR.responseXML;
> }
> catch (e)
> {
> _myexception = e;
> return _dummpyResponseXML;
> }
> }
> return _innerResponseXML;
>
> My try catch would not catch null. And the exception would be passed on
> to my callers, which is not what I wanted.

Indeed.

> > > If we are going to spec it to accommodate all existing browsers, we
> > > would want to make it "return null or INVALID_STATE_ERR exception".
> >
> > We want interoperable behaviour, so defining it in this way would be a
> > bad idea. (I don't really have an opinion either way about exception
> > vs null, but it seems that we should just pick whatever is most
> > commonly implemented, which I'm guessing is what Anne did here.)
>
> Fair enough. So let's pick one.
>
> What is "commonly implemented"? Is it largest browser market share?

Since the cost to implementations for fixing the problem is independent of
the size of the user base, it would be based just on the number of
independent implementations.

> Is it number of enterprise applications written on top of particular
> browser?

All the browsers want to be compatible with the Web, so if there are mroe
Web sites depending on the exception behaviour than the null behaviour,
then we clearly should do the exception behaviour. And vice versa. Do we
have any good numbers on this? (That there are widely deployed browsers
that return null instead of throwing an exception tends to suggest that
Web pages don't depend on either behaviour; we'd probably need evidence
to the contrary to decide one way or the other based on compatibility.)

> Is it the number of browers, in which case I hope my fictional
> home grown personal browser gets a vote :-)

Obviously fictional browsers aren't relevant, since the cost of fixing a
fictional browser is zero.

> From a pure technical point of view, predictably throw exception on
> state violations is easier to understand. I hope you would agree there
> is value to change spec for the sake of consistent programming model
> (which happens to be the IE model).

Indeed.

> Did the spec call out that responseXML returned from XHR should have
> equivalent DOM support as UA's object? If it is, that would be a good
> topic for us to debate about.

I believe the spec just says that you return a Document object; it is the
lack of a distinction between different Document objects that requires the
level of support to be the same. As you said, a consistent programming
model has value.

> I disagree that because DOM Level 3 is 3+ yr old spec that every UA has
> to support it in order to be XHR compliant, if that is what you implied.

I didn't mean to imply that. I don't think XHR should require any
particular level of support.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-17T01:29:12Z

Exceptional situation in general doesn't hinder interoperability. It only
becomes an issue if it is clearly stated in W3C spec and used as
a way to measure if UA is compliant.

We have provided our feedback to write spec in a away all current browsers
are complaint. If the general sentiment is to pick one model, then lets pick
the exception model, which is the model original XHR inventors picked.

Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is better.
If original XHR picked the null model, then we should go null model.
The important thing really is consistency, thus predictability.

Thanks!
Zhenbin

> -----Original Message-----
> From: Jonas Sicking [mailto:jonas@...]
> Sent: Monday, June 16, 2008 2:13 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> webapps@...
> Subject: Re: <Further LC Followup from IE> RE: Potential bugs
> identified in XHR LC Test Suite
>
> Zhenbin Xu wrote:
> > The issue of return "null or an exception" is simply a compromise
> > here. IE would throw an exception for state violations. Accessing
> > responseXML before open() is a state violation so it would trigger
> > exception. Other browsers may return null in such situation. In
> order
> > to accommodate all browsers, the spec would have to be rewritten in
> > some way.
>
> Please note that it is not a goal for the spec to be written in such a
> way that all existing browsers are conforming to the spec. It turned
> out
> that it was impossible to write a spec with that goal while still
> keeping the spec useful. So we no longer try to "accomodate all
> browsers", but instead write a spec that leads to interoperability
> between browsers.
>
> > We would certainly love to have the spec change to "MUST throw
> > INVALID_STATE_ERR exception", which is consistent with other
> > INVALID_STATE_ERR cases. For instance, the spec says if send() is
> > called before OPENED, it should trigger INVALID_STATE_ERR exception.
> > Another example is that user agent must raise INVALID_STATE_ERR if
> > "status" is not available. responseText and responseXML are the
> > outlier in the spec.
>
> Personally I think it makes more sense to return 'null' from
> .responseXML. We at mozilla have not had any interoperability problems
> with this behavior. Exceptions are better left for exceptional
> circumstances.
>
> However I can't say that I think the behavior is very important to me
> one way or another, as long as it's usefully defined.
>
> Best Regards,
> Jonas Sicking
>

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-17T01:16:59Z

Inline...

> -----Original Message-----
> From: Ian Hickson [mailto:ian@...]
> Sent: Sunday, June 15, 2008 11:46 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> webapps@...
> Subject: RE: <Further LC Followup from IE> RE: Potential bugs
> identified in XHR LC Test Suite
>
> On Sun, 15 Jun 2008, Zhenbin Xu wrote:
> > Ian wrote:
> > > On Wed, 11 Jun 2008, Sunava Dutta wrote:
> > > >
> > > > When Parsing Error happens, IE would still retain responseXML and
> > > > put error information on the object. Isnt this better than null
> as
> > > > there�s more relevant information for the web developer?
> > >
> > > How does one distinguish a document returned with parse error
> > > information from one that happens to look like a parse error but
> was
> > > well-formed?
> > >
> > > I wouldn't mind including more information but it seems like it
> should
> > > be out-of-band.
> >
> > I am not sure if I understand your question. responseXML.parseError
> has
> > the error information
> > http://msdn.microsoft.com/en-us/library/aa926483.aspx
>
> Oh, I assumed Sunava meant a conforming Document object was returned. A
> parseError-type object would be what I had in mind, yes. However, if we
> do
> this, then we should specify it. If we don't specify it, I'd rather
> have
> an exception.
>

[Zhenbin] The spec can simply state that a conforming document object
is returned, which includes out-of-band error information. This is what
IE does today and is a very reasonable approach that allows rich error
information for debugging.

>
> > > > The test is expecting us to return NULL in case open() has not
> been
> > > > called. We throw an exception in IE. I�d pre fer if the spec
> > > > says �MUST return null OR an exception� otherwise I fear sites
> > > > today will be broken.
> > >
> > > If a site is expecting an exception and gets null, then they'll get
> an
> > > exception when they try to dereferene the null, so in most cases it
> > > seems like this would work anyway.
> >
> > Properly written sites would have no problem one way or the other.
> > However if someone is writing a wrapper on top of XMLHTTP, clearly it
> > would make a difference on how to expose wrapped properties.
>
> Not really; if the script is expecting an exception, and receives null
> instead, then they'll just get an exception as soon as they dereference
> the object, which in almost all cases will be straight away.
>
>

[Zhenbin] I should explain the scenario I talked about. For instance, if
I am to write a wrapper object myXHR, it makes a difference for me when I
do the following

myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;

My try catch would not catch null. And the exception would be passed on
to my callers, which is not what I wanted.

> > If we are going to spec it to accommodate all existing browsers, we
> > would want to make it "return null or INVALID_STATE_ERR exception".
>
> We want interoperable behaviour, so defining it in this way would be a
> bad
> idea. (I don't really have an opinion either way about exception vs
> null,
> but it seems that we should just pick whatever is most commonly
> implemented, which I'm guessing is what Anne did here.)
>
>

[Zhenbin] Fair enough. So let's pick one.

What is "commonly implemented"? Is it largest browser market share?
Is it number of enterprise applications written on top of particular browser?
Is it the number of browers, in which case I hope my fictional home grown
personal browser gets a vote :-)

From a pure technical point of view, predictably throw exception on state
violations is easier to understand. I hope you would agree there
is value to change spec for the sake of consistent programming model (which
happens to be the IE model).

>
> > > I think it's important that we test that the DOM returned from XHR
> is
> > > DOM Core conformant just like any other, so this seems like an
> > > important and relevant testing area for XHR.
> >
> > That is not necessarily a good idea because you would then have to
> > mandate which level of DOM Core support is required. And if the spec
> > requires DOM level 3, that is big barrier for new user agent that
> wants
> > to be compliant with XHR spec.
> >
> > getElementById requires DOM Level 2. At the least the testing case
> can
> > be changed to use getElementByTagName, which is DOM level 1.
>
> I think expecting DOM Level 3 is the least of our worries -- after all,
> that's a 3+ year old spec. So testing just DOM Level 2 is really not a
> problem as far as I can tell. However, I agree that it would make sense
> to
> make the test pass if the UA didn't support that level of DOM on
> "regular"
> DOM objects too. The key is just to make sure that the objects returned
> by
> XHR are of equivalent DOM support as the rest of the UA's objects.
>

[Zhenbin] Did the spec call out that responseXML returned from XHR should
have equivalent DOM support as UA's object? If it is, that would be a
good topic for us to debate about.

I disagree that because DOM Level 3 is 3+ yr old spec that every UA has to
support it in order to be XHR compliant, if that is what you implied. XMLHTTP
has proven to be extremely valuable for the past years without providing DOM
level 3 support or equivalent DOM support between UA and responseXML.

> --
> Ian Hickson U+1047E )\._.,--....,'``.
> fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-
> .;.'

Re: RE: Potential bugs identified in XHR LC Test Suite

2008-06-16T14:13:08Z

Zhenbin Xu wrote:
> The issue of return "null or an exception" is simply a compromise
> here. IE would throw an exception for state violations. Accessing
> responseXML before open() is a state violation so it would trigger
> exception. Other browsers may return null in such situation. In order
> to accommodate all browsers, the spec would have to be rewritten in
> some way.

Please note that it is not a goal for the spec to be written in such a
way that all existing browsers are conforming to the spec. It turned out
that it was impossible to write a spec with that goal while still
keeping the spec useful. So we no longer try to "accomodate all
browsers", but instead write a spec that leads to interoperability
between browsers.

> We would certainly love to have the spec change to "MUST throw
> INVALID_STATE_ERR exception", which is consistent with other
> INVALID_STATE_ERR cases. For instance, the spec says if send() is
> called before OPENED, it should trigger INVALID_STATE_ERR exception.
> Another example is that user agent must raise INVALID_STATE_ERR if
> "status" is not available. responseText and responseXML are the
> outlier in the spec.

Personally I think it makes more sense to return 'null' from
.responseXML. We at mozilla have not had any interoperability problems
with this behavior. Exceptions are better left for exceptional
circumstances.

However I can't say that I think the behavior is very important to me
one way or another, as long as it's usefully defined.

Best Regards,
Jonas Sicking

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-15T23:45:30Z

On Sun, 15 Jun 2008, Zhenbin Xu wrote:

> Ian wrote:
> > On Wed, 11 Jun 2008, Sunava Dutta wrote:
> > >
> > > When Parsing Error happens, IE would still retain responseXML and
> > > put error information on the object. Isnt this better than null as
> > > there�s more relevant information for the web developer?
> >
> > How does one distinguish a document returned with parse error
> > information from one that happens to look like a parse error but was
> > well-formed?
> >
> > I wouldn't mind including more information but it seems like it should
> > be out-of-band.
>
> I am not sure if I understand your question. responseXML.parseError has
> the error information
> http://msdn.microsoft.com/en-us/library/aa926483.aspx

Oh, I assumed Sunava meant a conforming Document object was returned. A
parseError-type object would be what I had in mind, yes. However, if we do
this, then we should specify it. If we don't specify it, I'd rather have
an exception.

> > > The test is expecting us to return NULL in case open() has not been
> > > called. We throw an exception in IE. I�d pre fer if the spec
> > > says �MUST return null OR an exception� otherwise I fear sites
> > > today will be broken.
> >
> > If a site is expecting an exception and gets null, then they'll get an
> > exception when they try to dereferene the null, so in most cases it
> > seems like this would work anyway.
>
> Properly written sites would have no problem one way or the other.
> However if someone is writing a wrapper on top of XMLHTTP, clearly it
> would make a difference on how to expose wrapped properties.

Not really; if the script is expecting an exception, and receives null
instead, then they'll just get an exception as soon as they dereference
the object, which in almost all cases will be straight away.

> If we are going to spec it to accommodate all existing browsers, we
> would want to make it "return null or INVALID_STATE_ERR exception".

We want interoperable behaviour, so defining it in this way would be a bad
idea. (I don't really have an opinion either way about exception vs null,
but it seems that we should just pick whatever is most commonly
implemented, which I'm guessing is what Anne did here.)

> > I think it's important that we test that the DOM returned from XHR is
> > DOM Core conformant just like any other, so this seems like an
> > important and relevant testing area for XHR.
>
> That is not necessarily a good idea because you would then have to
> mandate which level of DOM Core support is required. And if the spec
> requires DOM level 3, that is big barrier for new user agent that wants
> to be compliant with XHR spec.
>
> getElementById requires DOM Level 2. At the least the testing case can
> be changed to use getElementByTagName, which is DOM level 1.

I think expecting DOM Level 3 is the least of our worries -- after all,
that's a 3+ year old spec. So testing just DOM Level 2 is really not a
problem as far as I can tell. However, I agree that it would make sense to
make the test pass if the UA didn't support that level of DOM on "regular"
DOM objects too. The key is just to make sure that the objects returned by
XHR are of equivalent DOM support as the rest of the UA's objects.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-15T22:50:07Z

Inline...

-----Original Message-----
From: Ian Hickson [mailto:ian@...]
Sent: Wednesday, June 11, 2008 9:34 PM
To: Sunava Dutta
Cc: Web API public; IE8 Core AJAX SWAT Team; public-webapps@...
Subject: Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Some quick comments on some of the comments regarding the tests:

On Wed, 11 Jun 2008, Sunava Dutta wrote:
>
> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm
>
> When Parsing Error happens, IE would still retain responseXML and put
> error information on the object. Isnt this better than null as there�s
> more relevant information for the web developer?

How does one distinguish a document returned with parse error information
from one that happens to look like a parse error but was well-formed?

I wouldn't mind including more information but it seems like it should be
out-of-band.

[Zhenbin] I am not sure if I understand your question. responseXML.parseError
has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx

> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm
>
> The test is expecting us to return NULL in case open() has not been
> called. We throw an exception in IE. I�d pre fer if the spec says
> �MUST return null OR an exception� otherwise I fear sites today will be
> broken.

If a site is expecting an exception and gets null, then they'll get an
exception when they try to dereferene the null, so in most cases it seems
like this would work anyway.

[Zhenbin] Properly written sites would have no problem one way or the other.
However if someone is writing a wrapper on top of XMLHTTP, clearly it would
make a difference on how to expose wrapped properties. OTOH they likely already
have handled both cases (currently IE throws exceptions and others return null).
If we are going to spec it to accommodate all existing browsers, we would want
to make it "return null or INVALID_STATE_ERR exception". If we are going to
spec it "the right way", then I think throw exception is a more consistent design (see
my reply to Jonas).

> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm
> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm
>
> This test really doesn�t test XHR here. It seems to be focused on
> manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports
> getElementById for an XML document FYI). Also, if I'm barking up the
> wrong tree here please let me know!

I think it's important that we test that the DOM returned from XHR is DOM
Core conformant just like any other, so this seems like an important and
relevant testing area for XHR.

[Zhenbin] That is not necessarily a good idea because you would then have to
mandate which level of DOM Core support is required. And if the spec requires
DOM level 3, that is big barrier for new user agent that wants to be compliant
with XHR spec.

getElementById requires DOM Level 2. At the least the testing case can be
changed to use getElementByTagName, which is DOM level 1.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: RE: Potential bugs identified in XHR LC Test Suite

2008-06-15T22:05:45Z

The issue of return "null or an exception" is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way.

We would certainly love to have the spec change to "MUST throw INVALID_STATE_ERR exception", which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if "status" is not available. responseText and responseXML are the outlier in the spec.

Thanks!
Zhenbin

-----Original Message-----
From: Jonas Sicking [mailto:jonas@...]
Sent: Thursday, June 12, 2008 11:20 AM
To: Sunava Dutta
Cc: Web API public; IE8 Core AJAX SWAT Team; public-webapps@...
Subject: Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

> _http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_
>
> The test is expecting us to return NULL in case open() has not been
> called. We throw an exception in IE. I'd pre fer if the spec says
> *"*MUST return null OR an exception*"* otherwise I fear sites today will
> be broken.

How would that help sites that expect an exception, since it would still
be conforming for the UA to return null? If anything, your proposal
seems to make it harder for sites to code against the spec.

/ Jonas

Re: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

2008-06-15T17:42:41Z

Sunava - please, just send us (=public-webapps) the PDF you uploaded
to msdn.

-Regards, Art Barstow

On Jun 13, 2008, at 1:48 PM, ext Sunava Dutta wrote:

> Yes, we're working on this as we speak. I'll send out a copy once
> it's ready.
>
>> -----Original Message-----
>> From: public-webapps-request@... [mailto:public-webapps-
>> request@...] On Behalf Of Arthur Barstow
>> Sent: Thursday, June 12, 2008 3:46 AM
>> To: Sunava Dutta
>> Cc: Marc Silbey; public-webapps; public-webapi@... WG (public);
>> public-appformats; Eric Lawrence; Chris Wilson; David Ross; Mark
>> Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion
>> Subject: Need PDF of MS' input [Was Re: Seeking earlier feedback from
>> MS]
>>
>>
>> Sunava - as requested by several members of the WG, please send a PDF
>> version of this document directly to the public-webapps mail list.
>>
>> -Thanks, Art Barstow
>>
>>
>> On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:
>>
>>> Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
>>>
>>>
>>> ________________________________________
>>> From: Sunava Dutta
>>> Sent: Wednesday, June 11, 2008 8:24 PM
>>> To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;
>>> public-webapps@...
>>> Cc: arun@...; public-webapi@... WG (public); public-
>>> appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
>>> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
>>> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
>>> Proposal for Cross Site Requests]
>>>
>>> Woo hooo, my first mail to the new webapps alias! -:)
>>>
>>> Thanks for waiting for us to get feedback in from people across
>>> MSFT. As promised, here is the whitepaper on client side cross
>>> domain security articulating the security principles and challenges
>>> (high level and specifics ) of the current CS-XHR draft.
>>> I've also addressed the questions members raised in the FAQ.
>>>
>>> As Jonas and Art mention, in order to provide the opportunity for
>>> members to research and usefully discuss the contents and other
>>> issues, lets talk about our concerns among other items F2F in the
>>> first week of July.
>>>
>>> https://mail.windows.microsoft.com/OWA/redir.aspx?
>>> C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
>>> 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
>>> 2fProjectReleases.aspx%3fReleaseId%3d1157
>>>
>>> Look forward to hosting the members here in Redmond.
>>>
>>>
>>> ________________________________________
>>> From: public-webapi-request@... [public-webapi-request@...]
>>> On Behalf Of Sunava Dutta [sunavad@...]
>>> Sent: Friday, June 06, 2008 2:54 PM
>>> To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
>>> Cc: arun@...; public-webapi@... WG (public); public-
>>> appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
>>> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
>>> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
>>> Proposal for Cross Site Requests]
>>>
>>> Art, Jonas,
>>> Just a quick update. We've put a lot of effort into the paper and
>>> the good news is we're nearly done. It's going through a final peer-
>>> review to make sure we've received feedback from experts in the
>>> company including our security gurus. (Yes, they do exist at MSFT -
>> :))
>>>
>>> I'll be sending out the paper on Tuesday evening or Wednesday the
>>> latest. Thanks for waiting.
>>>
>>>> -----Original Message-----
>>>> From: Arthur Barstow [mailto:art.barstow@...]
>>>> Sent: Friday, May 16, 2008 5:06 AM
>>>> To: ext Jonas Sicking; Sunava Dutta
>>>> Cc: arun@...; public-webapi@... WG (public); public-
>>>> appformats@...; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris
>>>> Wilson;
>>>> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
>>>> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal
>>>> for
>>>> Cross Site Requests]
>>>>
>>>> Sunava - I tend to agree with Jonas re the timing of MS' response/
>>>> feedback.
>>>>
>>>> Given the f2f meeting is now about six weeks away, can you
>>>> commit to
>>>> and deliver on an earlier deadline, no later than June 6?
>>>>
>>>> -Regards, Art Barstow

Re: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

2008-06-13T13:53:02Z

Sunava Dutta wrote:
> Woo hooo, my first mail to the new webapps alias! -:)
>
> Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft.
> I've also addressed the questions members raised in the FAQ.

Thanks Sunava, I look forward to reading this once it is available in an
acceptable license.

However, I would further hope that you are able to discuss the feedback
that are sure to be raised? As with your initial feedback, much of the
results of these discussions will also require research and so it is
good if we can get as much done before the face to face as possible.

> As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July.

Yes, though I do want to point out that there are many other issues too
to discuss at the F2F other than microsofts feedback.

Speaking of which, do we have an agenda yet for the F2F meeting?

> Look forward to hosting the members here in Redmond.

Looking forward to seeing you there!

Best Regards,
Jonas Sicking

RE: Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

2008-06-13T10:48:25Z

Yes, we're working on this as we speak. I'll send out a copy once it's ready.

> -----Original Message-----
> From: public-webapps-request@... [mailto:public-webapps-
> request@...] On Behalf Of Arthur Barstow
> Sent: Thursday, June 12, 2008 3:46 AM
> To: Sunava Dutta
> Cc: Marc Silbey; public-webapps; public-webapi@... WG (public);
> public-appformats; Eric Lawrence; Chris Wilson; David Ross; Mark
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu; Michael Champion
> Subject: Need PDF of MS' input [Was Re: Seeking earlier feedback from
> MS]
>
>
> Sunava - as requested by several members of the WG, please send a PDF
> version of this document directly to the public-webapps mail list.
>
> -Thanks, Art Barstow
>
>
> On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:
>
> > Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
> >
> >
> > ________________________________________
> > From: Sunava Dutta
> > Sent: Wednesday, June 11, 2008 8:24 PM
> > To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;
> > public-webapps@...
> > Cc: arun@...; public-webapi@... WG (public); public-
> > appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for Cross Site Requests]
> >
> > Woo hooo, my first mail to the new webapps alias! -:)
> >
> > Thanks for waiting for us to get feedback in from people across
> > MSFT. As promised, here is the whitepaper on client side cross
> > domain security articulating the security principles and challenges
> > (high level and specifics ) of the current CS-XHR draft.
> > I've also addressed the questions members raised in the FAQ.
> >
> > As Jonas and Art mention, in order to provide the opportunity for
> > members to research and usefully discuss the contents and other
> > issues, lets talk about our concerns among other items F2F in the
> > first week of July.
> >
> > https://mail.windows.microsoft.com/OWA/redir.aspx?
> > C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
> > 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
> > 2fProjectReleases.aspx%3fReleaseId%3d1157
> >
> > Look forward to hosting the members here in Redmond.
> >
> >
> > ________________________________________
> > From: public-webapi-request@... [public-webapi-request@...]
> > On Behalf Of Sunava Dutta [sunavad@...]
> > Sent: Friday, June 06, 2008 2:54 PM
> > To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
> > Cc: arun@...; public-webapi@... WG (public); public-
> > appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
> > Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> > Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> > Proposal for Cross Site Requests]
> >
> > Art, Jonas,
> > Just a quick update. We've put a lot of effort into the paper and
> > the good news is we're nearly done. It's going through a final peer-
> > review to make sure we've received feedback from experts in the
> > company including our security gurus. (Yes, they do exist at MSFT -
> :))
> >
> > I'll be sending out the paper on Tuesday evening or Wednesday the
> > latest. Thanks for waiting.
> >
> >> -----Original Message-----
> >> From: Arthur Barstow [mailto:art.barstow@...]
> >> Sent: Friday, May 16, 2008 5:06 AM
> >> To: ext Jonas Sicking; Sunava Dutta
> >> Cc: arun@...; public-webapi@... WG (public); public-
> >> appformats@...; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris
> >> Wilson;
> >> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> >> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal
> >> for
> >> Cross Site Requests]
> >>
> >> Sunava - I tend to agree with Jonas re the timing of MS' response/
> >> feedback.
> >>
> >> Given the f2f meeting is now about six weeks away, can you commit to
> >> and deliver on an earlier deadline, no later than June 6?
> >>
> >> -Regards, Art Barstow
> >>
> >>
> >> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
> >>
> >>>
> >>> Sunava Dutta wrote:
> >>>>>> This message is not attempting to set forth in detail all the
> >>>>> objections we have had; Sunava will >deliver that in a concise
> >>>>> form.
> >>>>>
> >>>>> Can you give us a ballpark ETA on this?
> >>>> [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> >>> this to
> >>>> be ready and available to the Web API by mid June in the latest.
> >>>
> >>> Wow, this is really bad news that we won't get this feedback until
> >>> just two weeks before the face to face meeting. Especially given
> >>> the numerous delays in getting this feedback in the past I am very
> >>> worried that there will be further delays. Are you absolutely
> >>> certain that won't happen again?
> >>>
> >>> Even just having two weeks in order to discuss this feedback prior
> >>> to the meeting seems like very short on time.
> >>>
> >>> I would really encourage you to consider providing this feedback
> >>> more promptly. I do not wish to attend a face to face meeting
> >>> solely to discuss new feedback which we have not had the
> >>> opportunity to research and cannot usefully discuss. I also hope to
> >>> cover much more than microsofts feedback during the meeting.
>
>

Re: [Progress events] There is no way to create progress events using document.createEvent

2008-06-13T04:52:52Z

On Thu, 05 Jun 2008 17:50:46 +0200, Olli Pettay <Olli.Pettay@...>
wrote:

> Hi all,
>
> PE seems to miss the eventType string for progress events so that
> document.createEvent could be used to create such events.
>
> The eventType string should be "ProgressEvent"

This seems to make sense to me. I raised ISSUE-3 to remind me (since it
requires thinking, right now is not when I will figure it out)

Cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com

Re: [progress-events] loaded member misnamed?

2008-06-13T04:43:09Z

Reply-to set to webapps - note we are in a transition...

On Wed, 28 May 2008 13:01:13 +0200, Anne van Kesteren <annevk@...>
wrote:

> Hi,
>
> Yesterday someone contacted me on IRC about implementing
> XMLHttpRequest.upload from XMLHttpRequest Level 2. It turns out that the
> Progress Events specification is not generic enough for both uploading
> and downloading as we agreed it should be long ago.
>
> The ProgressEvent.loaded member should probably be defined in a more
> abstract way

Can you explain in more detail what should be changed? (Feel free to raise
a new issue for this in the webapps tracker - otherwise I will when I
understasnd a bit more clearly what the issue is about).

> and I would actually suggest to rename it to ProgressEvent.transferred
> so it's clear that it is about transferred data.

Probably, but like many things we inherited a name and there are existing
implementations using it, so it seemed sensible to keep the names stable.

This is issue 119 [1] in the webapi tracker

[1] http://www.w3.org/2006/webapi/track/issues/119

cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com

Re: [progress-events]Some comments

2008-06-13T04:43:08Z

On Thu, 29 May 2008 13:10:50 +0200, Olli Pettay <Olli.Pettay@...>
wrote:

> Hi all,
>
> some more comments:
>
> (1)
> "typeArg of type DOMString
> This must be one of loadstart, progress, error, abort, load. If it
> is not one of those values then this specification does not define
> the resulting event..."
>
> I'd reword that somehow and definitely remove the "must be" part, since
> the type doesn't have to be one of those event types.

Agreed. I changed the wording in my local draft (so will appear in the
next editor's draft shortly)

> (2)
> "canBubbleArg of type boolean
> Specifies Event.bubbles. This parameter overrides the intrinsic
> bubbling behavior of the event and determines whether the event
> created will bubble
> cancelableArg of type boolean
> Specifies Event.cancelable. This parameter overrides the intrinsic
> cancel behavior of the event and determines whether the event
> created is cancelable"
>
> I know that is copied from DOM 3 Events draft, but 'intrinsic bubbling
> behavior' and 'intrinsic cancel behavior' aren't actually defined
> anywhere. Perhaps should modify that in DOM 3 Events.

That makes sense to me (plus it means I don't need to do anything new ;)

> Sentences should end to a .

Changed for the cases noted.

> (3)
> "If the user agent has reliable information about the value of total,
> then this should be true. If the user agent does not have reliable
> information about the vale of total, this should be false"
> vale -> value and . after false

Done.

> (4)
> Missing "informative" for example in chapter
> 'Using progress events in Web content'

Done

> Other comments
> http://lists.w3.org/Archives/Public/public-webapi/2008May/0349.html
> http://lists.w3.org/Archives/Public/public-webapi/2008May/0478.html

Yep. Thanks for the various comments, by the way. It's nice to have the
feedback ;)

cheers

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com

Re: Progress Events

2008-06-13T04:43:07Z

On Fri, 23 May 2008 18:25:36 +0200, Olli Pettay <Olli.Pettay@...>
wrote:

> Hi all,
>
> Because the user agent must support DOM events, the following text
> could be removed:
> "User agents must ensure that these events trigger event listeners
> attached on Element nodes for that event and on the capture and target
> phases."
> That text is anyway a bit strange, especially when progress events are
> used with XHR.

The text is a bit strange. It was added in response to Ian's mail saying
he had difficuly understanding which requirements applied to which
implementations, as part of the attempt to provide more explicit
requirements. There is no formal requirement in the current draft that
user agents implement DOM events - but perhaps that would be a simpler way
of setting the requirement?

> And it would be great to mark chapters to be either normative or
> non-normative. And numbering the chapters would be great
> too.

I agree, and will do both of these for or before the next public draft.

cheers and thanks for the comments

Chaals

--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com

Re: RE: Potential bugs identified in XHR LC Test Suite

2008-06-12T11:19:37Z

> _http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_
>
> The test is expecting us to return NULL in case open() has not been
> called. We throw an exception in IE. I’d pre fer if the spec says
> *“*MUST return null OR an exception*”* otherwise I fear sites today will
> be broken.

How would that help sites that expect an exception, since it would still
be conforming for the UA to return null? If anything, your proposal
seems to make it harder for sites to code against the spec.

/ Jonas

Need PDF of MS' input [Was Re: Seeking earlier feedback from MS]

2008-06-12T03:45:42Z

Sunava - as requested by several members of the WG, please send a PDF
version of this document directly to the public-webapps mail list.

-Thanks, Art Barstow

On Jun 11, 2008, at 11:36 PM, ext Sunava Dutta wrote:

> Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp
>
>
> ________________________________________
> From: Sunava Dutta
> Sent: Wednesday, June 11, 2008 8:24 PM
> To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey;
> public-webapps@...
> Cc: arun@...; public-webapi@... WG (public); public-
> appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> Proposal for Cross Site Requests]
>
> Woo hooo, my first mail to the new webapps alias! -:)
>
> Thanks for waiting for us to get feedback in from people across
> MSFT. As promised, here is the whitepaper on client side cross
> domain security articulating the security principles and challenges
> (high level and specifics ) of the current CS-XHR draft.
> I've also addressed the questions members raised in the FAQ.
>
> As Jonas and Art mention, in order to provide the opportunity for
> members to research and usefully discuss the contents and other
> issues, lets talk about our concerns among other items F2F in the
> first week of July.
>
> https://mail.windows.microsoft.com/OWA/redir.aspx?
> C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%
> 2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%
> 2fProjectReleases.aspx%3fReleaseId%3d1157
>
> Look forward to hosting the members here in Redmond.
>
>
> ________________________________________
> From: public-webapi-request@... [public-webapi-request@...]
> On Behalf Of Sunava Dutta [sunavad@...]
> Sent: Friday, June 06, 2008 2:54 PM
> To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
> Cc: arun@...; public-webapi@... WG (public); public-
> appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark
> Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: RE: Seeking earlier feedback from MS [Was: IE Team's
> Proposal for Cross Site Requests]
>
> Art, Jonas,
> Just a quick update. We've put a lot of effort into the paper and
> the good news is we're nearly done. It's going through a final peer-
> review to make sure we've received feedback from experts in the
> company including our security gurus. (Yes, they do exist at MSFT -:))
>
> I'll be sending out the paper on Tuesday evening or Wednesday the
> latest. Thanks for waiting.
>
>> -----Original Message-----
>> From: Arthur Barstow [mailto:art.barstow@...]
>> Sent: Friday, May 16, 2008 5:06 AM
>> To: ext Jonas Sicking; Sunava Dutta
>> Cc: arun@...; public-webapi@... WG (public); public-
>> appformats@...; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris
>> Wilson;
>> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
>> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal
>> for
>> Cross Site Requests]
>>
>> Sunava - I tend to agree with Jonas re the timing of MS' response/
>> feedback.
>>
>> Given the f2f meeting is now about six weeks away, can you commit to
>> and deliver on an earlier deadline, no later than June 6?
>>
>> -Regards, Art Barstow
>>
>>
>> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>>
>>>
>>> Sunava Dutta wrote:
>>>>>> This message is not attempting to set forth in detail all the
>>>>> objections we have had; Sunava will >deliver that in a concise
>>>>> form.
>>>>>
>>>>> Can you give us a ballpark ETA on this?
>>>> [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
>>> this to
>>>> be ready and available to the Web API by mid June in the latest.
>>>
>>> Wow, this is really bad news that we won't get this feedback until
>>> just two weeks before the face to face meeting. Especially given
>>> the numerous delays in getting this feedback in the past I am very
>>> worried that there will be further delays. Are you absolutely
>>> certain that won't happen again?
>>>
>>> Even just having two weeks in order to discuss this feedback prior
>>> to the meeting seems like very short on time.
>>>
>>> I would really encourage you to consider providing this feedback
>>> more promptly. I do not wish to attend a face to face meeting
>>> solely to discuss new feedback which we have not had the
>>> opportunity to research and cannot usefully discuss. I also hope to
>>> cover much more than microsofts feedback during the meeting.

Re: RE: Potential bugs identified in XHR LC Test Suite

2008-06-11T21:34:11Z

Some quick comments on some of the comments regarding the tests:

On Wed, 11 Jun 2008, Sunava Dutta wrote:
>
> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm
>
> When Parsing Error happens, IE would still retain responseXML and put
> error information on the object. Isnt this better than null as there�s
> more relevant information for the web developer?

How does one distinguish a document returned with parse error information
from one that happens to look like a parse error but was well-formed?

I wouldn't mind including more information but it seems like it should be
out-of-band.

> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm
>
> The test is expecting us to return NULL in case open() has not been
> called. We throw an exception in IE. I�d pre fer if the spec says
> �MUST return null OR an exception� otherwise I fear sites today will be
> broken.

If a site is expecting an exception and gets null, then they'll get an
exception when they try to dereferene the null, so in most cases it seems
like this would work anyway.

> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm
> http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm
>
> This test really doesn�t test XHR here. It seems to be focused on
> manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports
> getElementById for an XML document FYI). Also, if I'm barking up the
> wrong tree here please let me know!

I think it's important that we test that the DOM returned from XHR is DOM
Core conformant just like any other, so this seems like an important and
relevant testing area for XHR.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

2008-06-11T20:41:57Z

On Wed, 11 Jun 2008, Sunava Dutta wrote:
>
> Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp

Could you forward the paper to the list? (Preferably as plain text, though
HTML or PDF would do in a pinch.)

It's not clear to me whether the paper on that site is actually covered by
the license on that page, and I don't really want to run the risk of
committing Google to a license by accident without speaking to our lawyers
first, and that seems like a bit of an extreme to go to just to see your
feedback. :-)

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

RE: Potential bugs identified in XHR LC Test Suite

2008-06-11T20:37:27Z

2nd email to the new alias from me!

Dev, test and I ran a few more tests and had some results to share. A few of these should probably be clarified in the LC draft or the test cases should change.

Details below...

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm

When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there’s more relevant information for the web developer?

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm

The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I’d pre fer if the spec says “MUST return null OR an exception” otherwise I fear sites today will be broken.

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm

This test really doesn’t test XHR here. It seems to be focused on manipulating the XML DOM. (I also don’t think Microsoft.XMLDOM supports getElementById for an XML document FYI). Also, if I'm barking up the wrong tree here please let me know!

http://tc.labs.opera.com/apis/XMLHttpRequest/open/032.htm

What's the purpose of this test case and which part of spec is it testing? It’s difficult to understand that.

http://tc.labs.opera.com/apis/XMLHttpRequest/abort/003.htm

The abort() method resets event listeners. I’m looking at the 4/15 spec (on W3C site) and was wondering where this is specified?

http://tc.labs.opera.com/apis/XMLHttpRequest/onreadystatechange/004.htm

We don't raise onreadystatechange events from within the onreadystatechange event handler as there's danger of recursion. FYI I can't find any guidance here in the spec.

http://tc.labs.opera.com/apis/XMLHttpRequest/send/009.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/017.htm

Another dependency on e.code (As mentioned in the previous round of feedback on these tests. We can’t actually run the test until this is removed.

http://tc.labs.opera.com/apis/XMLHttpRequest/send/011.htm

In this test send(1) doesn’t work. The reason being we don’t cast an argument to a string. This is also not defined in the spec.

Thanks!

From: Sunava Dutta
Sent: Thursday, June 05, 2008 7:47 PM
To: Web API public; IE8 Core AJAX SWAT Team
Subject: Potential bugs identified in XHR LC Test Suite

Thanks for writing these cases by LC exit. It really makes the process of providing feedback prior to CR a lot easier. I ran these (the tests below fail on Safari3 ,Firefox 3 and IE8) with my team and had a few questions. If these issues can be addressed we can give further feedback and recommendations on the results/implementations. (Let me know if I’m wrong on our test analysis!) The rest of the tests that fail (without issues in the test itself) are being investigated further by my team so expect more over the next few days as we dig in.

http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm

This test seems to have a bug even though it passes. Line 24 uses top.opener.rr. The framework reports FAIL although the test passes.

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/004.php

http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/readyState/002.htm

These tests seem to be failing when the test autorun is used in IE. Running the tests individually causes them to pass on IE8. Looks like a bug in the test framework.

http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/005.php

This test fails because the network timeout is too short and passes sometimes (Unpredictable).

http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm

This seems to be a minor test bug. The file we are receiving does not contain the string “PASS”, which is necessary for the test to pass.

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm

The exception object here is not directly supported by IE, causing us to fail here. Can the test be tweaked so we can test the XHR compliance here? Thanks!

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm

The PHP page doesn’t seem to be producing valid content

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/034.php

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/035.php

Server-side PHP seems to be causing the test to pass or fail and we can’t determine the PASS criteria. May we get a pointer to the source here? (I think this was given a long time before but I can’t seem to dig it up!)

Meanwhile, I’d like to re-iterate a point I had raised up awhile back. Are the tests going to be ‘complete’ /comprehensive at CR in relation to the spec? MSFT obviously wants this test suite to be official ensuring that third parties do not write individual test cases undermining the credibility of the suite and demonstrating increased/decreased compliance post CR (when it’s much harder to make changes).

Thanks!

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

2008-06-11T20:36:17Z

Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp

________________________________________
From: Sunava Dutta
Sent: Wednesday, June 11, 2008 8:24 PM
To: Sunava Dutta; Arthur Barstow; ext Jonas Sicking; Marc Silbey; public-webapps@...
Cc: arun@...; public-webapi@... WG (public); public-appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.

________________________________________
From: public-webapi-request@... [public-webapi-request@...] On Behalf Of Sunava Dutta [sunavad@...]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: arun@...; public-webapi@... WG (public); public-appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news is we're nearly done. It's going through a final peer-review to make sure we've received feedback from experts in the company including our security gurus. (Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. Thanks for waiting.

> -----Original Message-----
> From: Arthur Barstow [mailto:art.barstow@...]
> Sent: Friday, May 16, 2008 5:06 AM
> To: ext Jonas Sicking; Sunava Dutta
> Cc: arun@...; public-webapi@... WG (public); public-
> appformats@...; IE8 Core AJAX SWAT Team; Eric Lawrence; Chris Wilson;
> David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
> Subject: Seeking earlier feedback from MS [Was: IE Team's Proposal for
> Cross Site Requests]
>
> Sunava - I tend to agree with Jonas re the timing of MS' response/
> feedback.
>
> Given the f2f meeting is now about six weeks away, can you commit to
> and deliver on an earlier deadline, no later than June 6?
>
> -Regards, Art Barstow
>
>
> On May 15, 2008, at 10:39 PM, ext Jonas Sicking wrote:
>
> >
> > Sunava Dutta wrote:
> >>> >This message is not attempting to set forth in detail all the
> >>> objections we have had; Sunava will >deliver that in a concise form.
> >>>
> >>> Can you give us a ballpark ETA on this?
> > > [Sunava Dutta] Sure, I'm compiling this as we speak. I expect
> > this to
> > > be ready and available to the Web API by mid June in the latest.
> >
> > Wow, this is really bad news that we won't get this feedback until
> > just two weeks before the face to face meeting. Especially given
> > the numerous delays in getting this feedback in the past I am very
> > worried that there will be further delays. Are you absolutely
> > certain that won't happen again?
> >
> > Even just having two weeks in order to discuss this feedback prior
> > to the meeting seems like very short on time.
> >
> > I would really encourage you to consider providing this feedback
> > more promptly. I do not wish to attend a face to face meeting
> > solely to discuss new feedback which we have not had the
> > opportunity to research and cannot usefully discuss. I also hope to
> > cover much more than microsofts feedback during the meeting.

RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

2008-06-11T20:24:49Z

Woo hooo, my first mail to the new webapps alias! -:)

Thanks for waiting for us to get feedback in from people across MSFT. As promised, here is the whitepaper on client side cross domain security articulating the security principles and challenges (high level and specifics ) of the current CS-XHR draft.
I've also addressed the questions members raised in the FAQ.

As Jonas and Art mention, in order to provide the opportunity for members to research and usefully discuss the contents and other issues, lets talk about our concerns among other items F2F in the first week of July.

https://mail.windows.microsoft.com/OWA/redir.aspx?C=7165bcd1f09048ac9fdcd34d2f9556b1&URL=http%3a%2f%2fcode.msdn.microsoft.com%2fxdsecuritywp%2fRelease%2fProjectReleases.aspx%3fReleaseId%3d1157

Look forward to hosting the members here in Redmond.

________________________________________
From: public-webapi-request@... [public-webapi-request@...] On Behalf Of Sunava Dutta [sunavad@...]
Sent: Friday, June 06, 2008 2:54 PM
To: Arthur Barstow; ext Jonas Sicking; Marc Silbey
Cc: arun@...; public-webapi@... WG (public); public-appformats@...; Eric Lawrence; Chris Wilson; David Ross; Mark Shlimovich (SWI); Doug Stamper; Zhenbin Xu
Subject: RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]

Art, Jonas,
Just a quick update. We've put a lot of effort into the paper and the good news is we're nearly done. It's going through a final peer-review to make sure we've received feedback from experts in the company including our security gurus. (Yes, they do exist at MSFT -:))

I'll be sending out the paper on Tuesday evening or Wednesday the latest. Thanks for waiting.

Re: Transitioning to WebApps Mailing List

2008-06-10T13:53:40Z

On Tue, 10 Jun 2008, Doug Schepers wrote:
>
> As for being subscribed to a list without being asked... I don't know.

Just position it as a list renaming. :-) Then they're aren't being
subscribed to a new list, so much as having an existing subscription
updated for their convenience.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Re: Transitioning to WebApps Mailing List

2008-06-10T13:48:49Z

Hi, Maciej-

Maciej Stachowiak wrote (on 6/10/08 12:18 PM):
>
> Would it be possible to just automatically subscribe members of both old
> lists to the new list, to smooth the transition?

Yes, it is possible.

I had thought of doing that, and got as far as concatenating a list of
all subscribers to all lists and diffing that with the current
subscribers to public-webapps... there's about 266 people subscribed to
public-webapi and public-appformats that aren't yet on public-webapps.
It would be easy enough for me to add them manually, with a notification
email sent to all new subscribers.

However...
1) some people may object to being autosubscribed
2) I don't know if there are IPP implications

I will check with our legal/comm people on the IPP issue tomorrow.

As for being subscribed to a list without being asked... I don't know.
On the one hand, these people are presumably already interested in the
topics because they subscribed to at least one of the lists (and there
was a lot of overlap), and they can easily unsubscribe... but on the
other, well, people are weird. What does everyone else think?

Like I said, I'm happy to do it if it's seen as a reasonable thing to
do. It would take me less time than it did to write this email, for
sure. :)

Regards-
-Doug Schepers
W3C Team Contact, WebApps, SVG, and CDF

RE: Microsoft Corp. has nominated Alec Berntson to Web API Working Group

2008-06-10T10:18:08Z

Yes - I will migrate over. Ideally I'd like to be on the geolocation WG when/if it gets going.

-----Original Message-----
From: Travis Leithead
Sent: Monday, June 09, 2008 9:34 PM
To: Sunava Dutta; Alec Berntson; Charles McCathieNevile; Michael Champion
Cc: public-webapi@...; Alec Berntson
Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API Working Group

(Except that this working group just closed down... :-)

Will you also be joining the web applications WG?

-----Original Message-----
From: public-webapi-request@... [mailto:public-webapi-request@...] On Behalf Of Sunava Dutta
Sent: Monday, June 09, 2008 2:31 PM
To: Alec Berntson; Charles McCathieNevile; Michael Champion
Cc: public-webapi@...; Alec Berntson
Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API Working Group

Good to have you here Alec!

> -----Original Message-----
> From: public-webapi-request@... [mailto:public-webapi-request@...]
> On Behalf Of Alec Berntson
> Sent: Friday, June 06, 2008 10:32 AM
> To: Charles McCathieNevile; Michael Champion
> Cc: public-webapi@...; Alec Berntson
> Subject: RE: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Thanks Chaals,
> My Name is Alec Berntson, and I work on a variety of location related
> projects at Microsoft. My interest in the group's work is primarily
> focused on the Geolocation API proposal, which I would very much like to
> see take off. My goal is to help define the specification and (hopefully)
> coordinate resources to test it.
>
> Cheers,
> Alec
>
>
> -----Original Message-----
> From: Charles McCathieNevile [mailto:chaals@...]
> Sent: Friday, June 06, 2008 2:37 AM
> To: sysbot+ipp@...; schepers@...; Michael Champion
> Cc: w3c-archive@...; Alec Berntson
> Subject: Re: Microsoft Corp. has nominated Alec Berntson to Web API
> Working Group
>
> Alec,
>
> welcome to WebAPI. Can you please send a brief intro to the group (either
> member-webapi@... or public-webapi@... is fine) including your
> interests in the group's work.
>
> Thanks in advance...
>
> cheers
>
> Chaals
>
> On Fri, 06 Jun 2008 04:52:01 +0200, <sysbot+ipp@...> wrote:
>
> > Dear AC Rep, Chair, Team Contact, and Participant,
> >
> > On June 6, 2008, 2:50 UTC, Alec Berntson became a participant in the
> Web
> > API Working Group. This person was nominated by Michael Champion
> >
> > This also implies that the following commitments were made:
> > - to have reviewed the Process Document on individual participant
> > qualifications ( section 3.1 [1]), Member participation in a Working
> > Group (section 6.2.1.1 [2]) - in particular that (1) the Member will
> > provide the necessary financial support for participation (e.g., for
> > travel, telephone calls, and conferences), and (2) the AC representative
> > attests that the individual accepts the participation terms set forth in
> > the charter [3] - and good standing (section 6.2.1.7 [4])
> > - to agree to the participation conditions described in the Working
> > Group
> > charter [3]
> >
> > For more information on Web API Working Group participation, see:
> > http://www.w3.org/2004/01/pp-impl/38482/status
> >
> > 1.
> > http://www.w3.org/2005/10/Process-
> 20051014/policies.html#ParticipationCriteria
> > 2. http://www.w3.org/2005/10/Process-20051014/groups.html#member-rep-wg
> > 3. http://www.w3.org/2006/webapi/admin/charter.html
> > 4. http://www.w3.org/2005/10/Process-20051014/groups.html#good-standing
> >
> >
> > This message has been sent by the W3C Working Group Management System.
>
>
>
> --
> Charles McCathieNevile Opera Software, Standards Group
> je parle français -- hablo español -- jeg lærer norsk
> http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com

Re: Transitioning to WebApps Mailing List

2008-06-10T09:18:48Z

Hi Doug,

Would it be possible to just automatically subscribe members of both
old lists to the new list, to smooth the transition?

On Jun 10, 2008, at 8:49 AM, Doug Schepers <schepers@...> wrote:

>
> Hi, WebApps Fans-
>
> As a follow-on to my previous invitation, I just wanted to give a
> tip about what I see as the easiest way to do this transition.
>
> Step 1: Join public-webapps ( http://lists.w3.org/Archives/Public/public-webapps/
> ); you need to do this explicitly even if you're a members of the
> WebApps WG;
>
> Step 2: When replying to an email thread on either public-webapi or
> public-appformats, add public-webapps to the recipients list;
>
> Step 3: When replying to an email thread on public-webapps, remove
> public-webapi or public-appformats from the recipients list, if they
> are on there.
>
> This way, we can have a fairly smooth transfer, though for some
> older issues, you may have to refer to some emails on one of the
> older lists.
>
> Thanks!
> -Doug Schepers
> W3C Team Contact, WebApps, SVG, and CDF
>