Re: IndexedDB: multientry or multiEntry?

[Jonas Sicking]

On Wed, Nov 30, 2011 at 6:22 PM, Tab Atkins Jr.  wrote:
> On Wed, Nov 30, 2011 at 6:11 PM, Israel Hilerio  wrote:
>> On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote:
>>> On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell  wrote:
>>> > Should the parameter used in IDBObjectStore.createIndex() and the
>>> > property on IDBIndex be spelled "multientry" (as it is in the spec
>>> > currently), or "multiEntry" (based on "multi-entry" as the correct English
>>> spelling)?
>>> >
>>> > Has any implementation shipped with the new name yet (vs. the old
>>> > "multirow")? Any strong preferences?
>>>
>>> Much of HTML uses all-lowercase names for similar things, both in markup
>>> and in the DOM.
>>>
>>> I would actually prefer to go the other way and change autoIncrement to
>>> autoincrement.
>>>
>>> / Jonas
>>>
>>
>> We currently have implemented the behavior per spec as "multientry" on our 
>> Win8 preview build and in follow on IE preview builds.  However, we would 
>> prefer for it to be camelCase since it matches the attributes we've already 
>> defined in the spec.  More important, this seems to match the web platform 
>> closer.  I believe the difference here is that these names are supposed to 
>> represent properties in a JS object which devs would expect to be camelCase 
>> like other attributes in the DOM spec.  I'm not sure about the markup 
>> argument. Also, if we end up making autoincrement all lower case, I would 
>> imagine we would want to be consistent and make keyPath all lower case too.  
>> This seems different.
>
> Agreed.  While HTML favors all-lowercase, JS and DOM favor camelCase.

While I still prefer multientry (and autoincrement and keypath), I
don't care that strongly.

So does this mean we should make the name both in the options object
and on IDBIndex(Sync) use multiEntry?

Also, I noticed that IDBObjectStore(Sync) doesn't expose
.autoIncrement. We should expose that right?

/ Jonas

Re: IndexedDB: multientry or multiEntry?

[Tab Atkins Jr.]

On Wed, Nov 30, 2011 at 6:11 PM, Israel Hilerio  wrote:
> On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote:
>> On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell  wrote:
>> > Should the parameter used in IDBObjectStore.createIndex() and the
>> > property on IDBIndex be spelled "multientry" (as it is in the spec
>> > currently), or "multiEntry" (based on "multi-entry" as the correct English
>> spelling)?
>> >
>> > Has any implementation shipped with the new name yet (vs. the old
>> > "multirow")? Any strong preferences?
>>
>> Much of HTML uses all-lowercase names for similar things, both in markup
>> and in the DOM.
>>
>> I would actually prefer to go the other way and change autoIncrement to
>> autoincrement.
>>
>> / Jonas
>>
>
> We currently have implemented the behavior per spec as "multientry" on our 
> Win8 preview build and in follow on IE preview builds.  However, we would 
> prefer for it to be camelCase since it matches the attributes we've already 
> defined in the spec.  More important, this seems to match the web platform 
> closer.  I believe the difference here is that these names are supposed to 
> represent properties in a JS object which devs would expect to be camelCase 
> like other attributes in the DOM spec.  I'm not sure about the markup 
> argument. Also, if we end up making autoincrement all lower case, I would 
> imagine we would want to be consistent and make keyPath all lower case too.  
> This seems different.

Agreed.  While HTML favors all-lowercase, JS and DOM favor camelCase.

~TJ

Re: [XHR] chunked

[Jonas Sicking]

On Wed, Nov 30, 2011 at 6:16 PM, Charles Pritchard  wrote:
> On 11/30/11 6:04 PM, Glenn Maynard wrote:
>
> On Wed, Nov 30, 2011 at 8:45 PM, Charles Pritchard  wrote:
>>
>> I don't worry about character sets at all. I treat the content as opaque.
>
>
> It doesn't sound like you're describing text processing at all, but binary
> processing of data that happens to contain text.
>
>
> Right, for chunked encoding, I start by treating it as binary data, and go
> from there.
> So, I'm not a good source for the usefulness of chunked-text.
>
> When I want text, I convert, but my default is more often to work with
> buffers.
>
> I think Jonas made a good point about multibyte boundaries in text. That's
> not something that can be solved by a simple method:
> str = UintToString(IntArrayBufferChunk);
>
> But it can be solved simply by delegating it to XHR and a chunked-type
> response.
>
> My only requirement is for chunked-arraybuffer, but I didn't mean to stand
> in the way of a chunked-text type.

The part of the original email that you responded to was specifically
talking about weather we should have chunked-text *as well as*
chunked-arraybuffer. So it seems like this sub-thread was off-topic to
that question.

/ Jonas

Re: [XHR] chunked

[Charles Pritchard]

On 11/30/11 6:04 PM, Glenn Maynard wrote:
On Wed, Nov 30, 2011 at 8:45 PM, Charles Pritchard > wrote:


I don't worry about character sets at all. I treat the content as
opaque. 



It doesn't sound like you're describing text processing at all, but 
binary processing of data that happens to contain text.


Right, for chunked encoding, I start by treating it as binary data, and 
go from there.

So, I'm not a good source for the usefulness of chunked-text.

When I want text, I convert, but my default is more often to work with 
buffers.


I think Jonas made a good point about multibyte boundaries in text. 
That's not something that can be solved by a simple method:

str = UintToString(IntArrayBufferChunk);

But it can be solved simply by delegating it to XHR and a chunked-type 
response.


My only requirement is for chunked-arraybuffer, but I didn't mean to 
stand in the way of a chunked-text type.


-Charles

RE: IndexedDB: multientry or multiEntry?

[Israel Hilerio]

On Wednesday, November 30, 2011 3:55 PM, Jonas Sicking wrote:
> On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell  wrote:
> > Should the parameter used in IDBObjectStore.createIndex() and the
> > property on IDBIndex be spelled "multientry" (as it is in the spec
> > currently), or "multiEntry" (based on "multi-entry" as the correct English
> spelling)?
> >
> > Has any implementation shipped with the new name yet (vs. the old
> > "multirow")? Any strong preferences?
> 
> Much of HTML uses all-lowercase names for similar things, both in markup
> and in the DOM.
> 
> I would actually prefer to go the other way and change autoIncrement to
> autoincrement.
> 
> / Jonas
> 

We currently have implemented the behavior per spec as "multientry" on our Win8 
preview build and in follow on IE preview builds.  However, we would prefer for 
it to be camelCase since it matches the attributes we've already defined in the 
spec.  More important, this seems to match the web platform closer.  I believe 
the difference here is that these names are supposed to represent properties in 
a JS object which devs would expect to be camelCase like other attributes in 
the DOM spec.  I'm not sure about the markup argument. Also, if we end up 
making autoincrement all lower case, I would imagine we would want to be 
consistent and make keyPath all lower case too.  This seems different.

Israel

Re: [XHR] chunked

[Glenn Maynard]

On Wed, Nov 30, 2011 at 8:45 PM, Charles Pritchard  wrote:

> I don't worry about character sets at all. I treat the content as opaque.


It doesn't sound like you're describing text processing at all, but binary
processing of data that happens to contain text.

-- 
Glenn Maynard

Re: [XHR] chunked

[Charles Pritchard]

On 11/30/11 3:44 PM, Jonas Sicking wrote:

On Wed, Nov 30, 2011 at 1:03 PM, Charles Pritchard  wrote:

On Nov 30, 2011, at 12:41 PM, Jonas Sicking  wrote:


On Wed, Nov 30, 2011 at 12:13 PM, Charles Pritchard  wrote:

On Nov 30, 2011, at 11:32 AM, Jonas Sicking  wrote:


Charles asked whether "chunked-text" was really needed (and whether we
should have "chunked" which implies ArrayBuffer instead). Nobody got back to
him on that.

Any text based format would benefit from chunked-text. While the
example above uses a binary format, it applies equally to text based
formats. And given how much we in this group seem to prefer text based
formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
assume that other people at least use them, if not prefer them.

My thinking was that ArrayBuffer can easily be converted to String by authors. 
Even with text-based formats, I prefer to fetch data as blob and buffer.

Why?

Because it helps with general methods to pass buffers around, and stream 
processing is buffer based. I don't need to worry about character sets or 
errant binary data. It's raw and easy to port, being a Transferable object.

Why couldn't you use strings instead of buffers when dealing with
textual data? And why don't you need need to worry less about


I can, it just requires extra calls to and from String.fromCharCode and 
charCodeAt. Using buffers is going to be faster, of course, as they are 
based on Typed Arrays, whenever I'm doing heavy computation. I do use 
strings. But for heavy processing and abstracted methods, I use buffers 
and typed arrays.



characters sets if you are doing the charset conversion rather than
the UA? I would imagine you'd have to worry more about character sets
if you take on that burden rather than let the UA do it.


I don't worry about character sets at all. I treat the content as 
opaque. If there's an error in the character set, that's up to some 
other part of the process to figure out. I treat the data as fairly 
opaque. I rarely am trying to sanitize or validate data. I'm just 
looking for particular values in it.



I can see the argument of being a Transferable object. But why
transfer the chunked data between threads? Just do the load on the
thread that is going to interpret the data.


That may often be the case, but when I transfer processed data back to 
the main thread, I still may want it as a buffer.
I've worked a lot on string processing, in old JS and JS with typed 
arrays. I've certainly ridden the ins and outs and use all methods 
available.



Many of my encoding and decoding methods expect byte arrays.

And these methods are dealing with textual data? Note that no-one is
proposing the ability to do chunked-arraybuffer. The question is if we
should have chunked-text as well.


It's a good question, I don't have an answer. I'd sure like an 
ArrayBuffer to string method. Converting to a Blob then using 
FileReader, is bit of extra work, as is running fromCharCode over the 
array to build a string.  A conversion method would make 
chunked-arraybuffer quite easy to convert into a string...


Your suggestion that chunked-text would always return complete 
multi-byte codes was pretty good, as is the notion that whatever 
chunked-text returns is DOMString-safe, so it'd always work with 
something like localStorage.setItem. And those are perhaps features that 
a conversion method would not handle as well,.


Sorry if I created confusion or chaos here. Just reporting on what I 
tend to do.



-Charles

RE: publish new WD of XHR; deadline December 5

[Adrian Bateman]

On Wednesday, November 30, 2011 5:43 AM, Arthur Barstow wrote:
> Anne completed his merge XHR and XHR2 merge and the new History section 
> includes information about the merge. As such, this is a Call for 
> Consensus to publish a new WD of XHR using the following ED (not yet 
> "pub ready") as the basis:
>
>http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html
>
> Agreement to this proposal: a) indicates support for publishing a new 
> WD; and b) does not necessarily indicate support of the contents of the WD.
>
> If you have any comments or concerns about this proposal, please send 
> them to public-webapps by December 5 at the latest.
>
> As with all of our CfCs, positive response is preferred and encouraged 
> and silence will be assumed to be agreement with the proposal.

I missed much of the discussion on this until now because of the holiday over
the weekend in the US. As I said at TPAC, I think continuing only with XHR2
in this exceptional circumstance is the right move provided the group doesn't
make a habit of dropping things because there's a newer shiny version.

With that in mind, I'd like to see the XHR1 document published as a WG Note.
I received a question just this morning asking about the expected behaviour for
an XHR implementation in a pre-CORS environment. While not perfect, the XHR1
document is a reasonably good record of the state of implementations prior to
CORS and I'm reluctant to lose that information or to have to rely on trying to
find a CR publication that doesn't even appear in the history of the new
document.

Secondly, at least within Microsoft and the web developers that I talk to,
the notion of XHR L2 is one that they're familiar with and understood to be
distinct from the original. Could we not continue to publish into TR space
using the "2" suffix?

Thanks,

Adrian.

Re: IndexedDB: multientry or multiEntry?

[Jonas Sicking]

On Wed, Nov 30, 2011 at 3:09 PM, Joshua Bell  wrote:
> Should the parameter used in IDBObjectStore.createIndex() and the property
> on IDBIndex be spelled "multientry" (as it is in the spec currently), or
> "multiEntry" (based on "multi-entry" as the correct English spelling)?
>
> Has any implementation shipped with the new name yet (vs. the old
> "multirow")? Any strong preferences?

Much of HTML uses all-lowercase names for similar things, both in
markup and in the DOM.

I would actually prefer to go the other way and change autoIncrement
to autoincrement.

/ Jonas

Re: [XHR] chunked

[Jonas Sicking]

On Wed, Nov 30, 2011 at 1:03 PM, Charles Pritchard  wrote:
> On Nov 30, 2011, at 12:41 PM, Jonas Sicking  wrote:
>
>> On Wed, Nov 30, 2011 at 12:13 PM, Charles Pritchard  wrote:
>>> On Nov 30, 2011, at 11:32 AM, Jonas Sicking  wrote:
>>>
> Charles asked whether "chunked-text" was really needed (and whether we
> should have "chunked" which implies ArrayBuffer instead). Nobody got back 
> to
> him on that.

 Any text based format would benefit from chunked-text. While the
 example above uses a binary format, it applies equally to text based
 formats. And given how much we in this group seem to prefer text based
 formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
 assume that other people at least use them, if not prefer them.
>>>
>>> My thinking was that ArrayBuffer can easily be converted to String by 
>>> authors. Even with text-based formats, I prefer to fetch data as blob and 
>>> buffer.
>>
>> Why?
>
> Because it helps with general methods to pass buffers around, and stream 
> processing is buffer based. I don't need to worry about character sets or 
> errant binary data. It's raw and easy to port, being a Transferable object.

Why couldn't you use strings instead of buffers when dealing with
textual data? And why don't you need need to worry less about
characters sets if you are doing the charset conversion rather than
the UA? I would imagine you'd have to worry more about character sets
if you take on that burden rather than let the UA do it.

I can see the argument of being a Transferable object. But why
transfer the chunked data between threads? Just do the load on the
thread that is going to interpret the data.

> Many of my encoding and decoding methods expect byte arrays.

And these methods are dealing with textual data? Note that no-one is
proposing the ability to do chunked-arraybuffer. The question is if we
should have chunked-text as well.

/ Jonas

IndexedDB: multientry or multiEntry?

[Joshua Bell]

Should the parameter used in IDBObjectStore.createIndex() and the property
on IDBIndex be spelled "multientry" (as it is in the spec currently), or
"multiEntry" (based on "multi-entry" as the correct English spelling)?

Has any implementation shipped with the new name yet (vs. the old
"multirow")? Any strong preferences?

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Tab Atkins Jr.]

On Wed, Nov 30, 2011 at 12:05 PM, Bjoern Hoehrmann  wrote:
> * Tab Atkins Jr. wrote:
>>Disclaimer: I'm a CSSWG member, was previously a web developer by
>>trade (now am a webkit engineer/spec author), and was only vaguely
>>aware of XPath a week ago.
>
> XPath support has been available in web browsers for over decade. If you
> have so far been unaware of it, that likely means you rarely if ever run
> into problems where XPath offers a good solution, and have basically no
> insight into the community that does. I on the other hand regularily run
> into such problems.

It's actually rather irrelevant for my point.  I'm claiming that the
two technologies are rivalrous, because they do the *exact same thing*
and can't be used together easily.  I also argue that supporting two
rivalrous techs in the platform is bad for authors.* Instead, it's
healthier for the platform if we choose only one of them to work on.

XPath is either better than Selectors, roughly the same, or worse (or
it's incomparable, which I don't think can be argued).  If it's the
former, we should develop XPath *only*, and stop working on Selectors
in JS APIs.  If it's the latter, we should develop Selectors *only*,
and stop working on XPath in JS APIs.  If it's the middle, we should
choose one or the other based on other factors and work on it only
(and possibly merge some functionality).  I argue that it's roughly
the same.  It does some things better than Selectors, but Selectors
does some things better than XPath.  I also argue that using
JS+Selectors is easier than using JS+XPath, because the missing
functionality in Selectors is simpler and maps better to easy JS
operations.  This, combined with the fact that Selectors is very
obviously popular and more well-known than XPath, suggests that we
should be favoring Selectors.

* If two rivalrous techs are relatively new or have little usage, it
can make sense to work on both of them until one emerges as a clear
winner.  At that point, though, only the winner should be worked on.
This is not the case for XPath and Selectors, though.


> Just this weekend I wrote an MP3 player. It hosts a web browser for the
> user interface to make it easy to adjust it for people who are familiar
> with technologies implemented by web browsers. One feature it has is na-
> vigation through the playlist using arrow keys. You have a track that is
> currently selected, "up" should go to the previous track, "down" to the
> next one, in playlist order.
>
> While there were various initiatives to standardize focus navigation in
> 2006 if I recall correctly, they have not quite materialized yet, so it
> takes scripting to implement this. Tracks in the playlist are table rows
> and so pressing "up" should move the cursor to the single node that is
> the previous table row from the perspective of the current one. That is
>
>  var previous = current.selectSingleNode("previous::tr")
>
> as it has been available in Internet Explorer for over a decade. There
> is no Selectors equivalent and the JavaScript code for this is rather
> involved. There is also no proposal for Selectors extensions, or Java-
> script or DOM or whatever extensions to make this considerably easier.
> Yes, those could be implemented, that argument is from the 1990s and it
> does not really result in actual implementations.
>
> Also note in particular that you can read the code above even without
> knowing anything about XPath and yet you will fully understand from the
> context it is used in what it does. It is how code should be written.

As Yehuda notes, this probably doesn't do what you want if there's
another table preceding the context element's table in the document,
since it'll go from the first row in your table to the last row in the
preceding table.

You likely want the previous row in the same table.  This is trivial
in JS if your table has only a single tbody, and also trivial in
Selectors with the subject indicator in the Selectors 4 draft (use
"tr! + tr:scope", or with the alternate :has() formulation, use
"tr:has( + tr:scope )").  If you have multiple tbodys, it's still
really easy in JS (if you're at the first row in the tbody, go up one
level and check if there's a preceding tbody, if so return its last
row).  It can't be done in the current Selectors 4 draft, but will be
doable with some planned extensions (it requires a little bit of
thinking, but it's not too horrible with :has()**).

I believe that a proper XPath expression for this would be similarly
complicated to the Selectors version.  I won't attempt it, though I
welcome someone else to do so.

** :matches(
 tr:has(+tr:scope),
 tbody:has(+tbody>tr:first-child:scope) > tr:last-child )

If you really do want the full power of XPath's preceding axis,
however, that's not trivial to write in either JS or Selectors.  If
Selectors had a combinator for descendant-or-self, it would be a
fairly simple one-liner, though.


>>In the recent discussions about XPath, I keep hearing

Re: TAG Comment on

[Noah Mendelsohn]

Thank you. Please let me know if there are any significant changes to the 
status of this.


Noah
Chair: W3C Technical Architecture Group

On 11/30/2011 12:57 PM, Arthur Barstow wrote:

Noah - FYI, I updated [Action-640] to include the TAG's comment [LC-2] (it
originally was only for Ashok's personal comment [Ashok]) and updated LC-2
to connect it to Action-640.

-AB

[Action-640] http://www.w3.org/2008/webapps/track/actions/640
[LC-2]
http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2
[Ashok]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0837.html

On 11/18/11 10:44 AM, ext Noah Mendelsohn wrote:

> Noah - the TAG's comment has been added to the comment tracking document
> for this LC:
>
> http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2

Thank you.

Noah

On 11/18/2011 10:01 AM, Arthur Barstow wrote:

Noah - the TAG's comment has been added to the comment tracking document
for this LC:

http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2

If anyone wants to propose extensions or changes to Web Storage, please use
[Bugzilla] and please feel free to contribute to the group's [Database]
wiki e.g. to clarify the relationship between Web Storage and HTML5's
AppCache.

If you have any additional feedback, please reply by November 25, the day
the CfC to publish a Candidate Recommendation of Web Storage ends [CfC].

-Art Barstow

[Bugzilla]
http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG
[Database] http://www.w3.org/2008/webapps/wiki/Database
[CfC]
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html

On 11/15/11 5:05 PM, ext Noah Mendelsohn wrote:

This is a comment from the W3C Technical Architecture Group on the last
call working draft: "Web Storage" [1].

The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both
provide client-side storage that can be used by Web Applications.
Although the interfaces are different (AppCache has an HTML interface
while Local Storage has a JavaScript API), and they do seem to have been
designed with different use cases in mind, they provide somewhat related
facilities: both cause persistent storage for an application to be
created, accessed and managed locally at the client. If, for example, the
keys in Local Storage were interpreted as URIs then Local Storage could
be used to store manifest files and Web Applications could be written to
look transparently for manifest files in either the AppCache or in Local
Storage. One might also envision common facilities for querying the size
of or releasing all of the local storage for a given application.

At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a
request for a JavaScript API for AppCache and talk about coordinating
AppCache and Local Storage.

The TAG believes it is important to consider more carefully the potential
advantages of providing a single facility to cover the use cases, of
perhaps modularizing the architecture so that some parts are shared, or
if separate facilities are indeed the best design, providing common data
access and manipulation APIs. If further careful analysis suggests that
no such integration is practical, then, at a minimum, each specification
should discuss how it is positioned with respect to the other.

Noah Mendelsohn
For the: W3C Technical Architecture Group

[1] http://www.w3.org/TR/2011/WD-webstorage-20111025/
[2] http://www.w3.org/TR/html5/offline.html#appcache
[3] http://www.w3.org/2011/web-apps-ws/

Re: Enable Compression Of A Blob To .zip File

[timeless]

I think crypto is supposed to be in scope of another WG that was being
chartered nowish

On 11/30/11, Joran Greef  wrote:
> It would be great to have a native binding to Zlib and Snappy exposed to
> Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy
> covers the expensive CPU use-cases.
>
> Also a native binding to basic crypto primitives, even if that means just
> SHA1 to start, and even if the Node.js crypto api is copied verbatim.
>
> TypedArrays are in current implementations are too slow to help with these,
> as far as I have tried.
>
>
>

-- 
Sent from my mobile device

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 1:22 PM, Bjoern Hoehrmann  wrote:

> * Yehuda Katz wrote:
> >Out of curiosity, I'd like to see the DOM in question, the starting
> element
> >and the element you were trying to select. I think "how people do it in
> the
> >real world" is actually relevant.
>
> There is a table for each album and in an album each tbody/tr element is
> a track in that album.
>

So you want the preceding tr, no matter where it is in the DOM, so that it
goes from the top tr in one table to the bottom tr in another?


> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Bjoern Hoehrmann]

* Yehuda Katz wrote:
>Out of curiosity, I'd like to see the DOM in question, the starting element
>and the element you were trying to select. I think "how people do it in the
>real world" is actually relevant.

There is a table for each album and in an album each tbody/tr element is
a track in that album.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 1:16 PM, James Graham  wrote:

>
>
> On Wed, 30 Nov 2011, Yehuda Katz wrote:
>
>
>> Yehuda Katz
>> (ph) 718.877.1325
>>
>>
>> On Wed, Nov 30, 2011 at 12:57 PM, Bjoern Hoehrmann 
>> wrote:
>>  * Yehuda Katz wrote:
>>  >Most people would accomplish that using jQuery. Something like:
>>  >
>>  >var previous = $(current).closest("tr").prev(**)
>>  >
>>  >I'm not exactly sure what `current` is in this case. What
>> edge-cases are
>>  >you worried about when you say that the JavaScript is "quite
>> involved"?
>>
>> It is unlikely that your code is equivalent to the code I provided, and
>> sure enough, you can point out in all discussions about convenience APIs
>> that people could use a library. I don't see how that is relevant here.
>>
>>
>> It's relevant because Tab's argument is that a mix of selectors and JS
>> APIs will work, and I'm demonstrating that by showing that that's what
>> *people actually do* today.
>>
>
> Of course that can be taken in one of two ways; it either shows that it's
> fine to have a limited selection DSL because people can fall back on using
> a full programming language, or shows that today's selction DSLs have
> failed because people are being forced to fall back on a full programming
> language and the whole of jQuery to satisfy their needs.
>

On the flip-side, jQuery gives us a good set of primitive DOM traversal
methods that people have used successfully to satisfy their needs. It would
probably be worth considering implementing some of them natively. Which is,
I think, Tab's point.

Re: XPath and Selectors are identical, and shouldn't be co-developed

[James Graham]

On Wed, 30 Nov 2011, Yehuda Katz wrote:



Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 12:57 PM, Bjoern Hoehrmann  wrote:
  * Yehuda Katz wrote:
  >Most people would accomplish that using jQuery. Something like:
  >
  >var previous = $(current).closest("tr").prev()
  >
  >I'm not exactly sure what `current` is in this case. What edge-cases are
  >you worried about when you say that the JavaScript is "quite involved"?

It is unlikely that your code is equivalent to the code I provided, and
sure enough, you can point out in all discussions about convenience APIs
that people could use a library. I don't see how that is relevant here.


It's relevant because Tab's argument is that a mix of selectors and JS APIs 
will work, and I'm demonstrating that by showing that that's what *people 
actually do* today.


Of course that can be taken in one of two ways; it either shows that it's 
fine to have a limited selection DSL because people can fall back on using 
a full programming language, or shows that today's selction DSLs have 
failed because people are being forced to fall back on a full programming 
language and the whole of jQuery to satisfy their needs.

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 12:57 PM, Bjoern Hoehrmann wrote:

> * Yehuda Katz wrote:
> >Most people would accomplish that using jQuery. Something like:
> >
> >var previous = $(current).closest("tr").prev()
> >
> >I'm not exactly sure what `current` is in this case. What edge-cases are
> >you worried about when you say that the JavaScript is "quite involved"?
>
> It is unlikely that your code is equivalent to the code I provided,


Out of curiosity, I'd like to see the DOM in question, the starting element
and the element you were trying to select. I think "how people do it in the
real world" is actually relevant.


> and
> sure enough, you can point out in all discussions about convenience APIs
> that people could use a library. I don't see how that is relevant here.
> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 12:57 PM, Bjoern Hoehrmann wrote:

> * Yehuda Katz wrote:
> >Most people would accomplish that using jQuery. Something like:
> >
> >var previous = $(current).closest("tr").prev()
> >
> >I'm not exactly sure what `current` is in this case. What edge-cases are
> >you worried about when you say that the JavaScript is "quite involved"?
>
> It is unlikely that your code is equivalent to the code I provided, and
> sure enough, you can point out in all discussions about convenience APIs
> that people could use a library. I don't see how that is relevant here.
>

It's relevant because Tab's argument is that a mix of selectors and JS APIs
will work, and I'm demonstrating that by showing that that's what *people
actually do* today.


> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>

Re: [XHR] chunked

[Charles Pritchard]

On Nov 30, 2011, at 12:41 PM, Jonas Sicking  wrote:

> On Wed, Nov 30, 2011 at 12:13 PM, Charles Pritchard  wrote:
>> On Nov 30, 2011, at 11:32 AM, Jonas Sicking  wrote:
>> 
 Charles asked whether "chunked-text" was really needed (and whether we
 should have "chunked" which implies ArrayBuffer instead). Nobody got back 
 to
 him on that.
>>> 
>>> Any text based format would benefit from chunked-text. While the
>>> example above uses a binary format, it applies equally to text based
>>> formats. And given how much we in this group seem to prefer text based
>>> formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
>>> assume that other people at least use them, if not prefer them.
>> 
>> My thinking was that ArrayBuffer can easily be converted to String by 
>> authors. Even with text-based formats, I prefer to fetch data as blob and 
>> buffer.
> 
> Why?

Because it helps with general methods to pass buffers around, and stream 
processing is buffer based. I don't need to worry about character sets or 
errant binary data. It's raw and easy to port, being a Transferable object.

Many of my encoding and decoding methods expect byte arrays.

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Bjoern Hoehrmann]

* Yehuda Katz wrote:
>Most people would accomplish that using jQuery. Something like:
>
>var previous = $(current).closest("tr").prev()
>
>I'm not exactly sure what `current` is in this case. What edge-cases are
>you worried about when you say that the JavaScript is "quite involved"?

It is unlikely that your code is equivalent to the code I provided, and
sure enough, you can point out in all discussions about convenience APIs
that people could use a library. I don't see how that is relevant here.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [XHR] chunked

[Jonas Sicking]

On Wed, Nov 30, 2011 at 12:13 PM, Charles Pritchard  wrote:
> On Nov 30, 2011, at 11:32 AM, Jonas Sicking  wrote:
>
>>> Charles asked whether "chunked-text" was really needed (and whether we
>>> should have "chunked" which implies ArrayBuffer instead). Nobody got back to
>>> him on that.
>>
>> Any text based format would benefit from chunked-text. While the
>> example above uses a binary format, it applies equally to text based
>> formats. And given how much we in this group seem to prefer text based
>> formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
>> assume that other people at least use them, if not prefer them.
>
> My thinking was that ArrayBuffer can easily be converted to String by 
> authors. Even with text-based formats, I prefer to fetch data as blob and 
> buffer.

Why?

/ Jonas

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Yehuda Katz]

Yehuda Katz
(ph) 718.877.1325


On Wed, Nov 30, 2011 at 12:05 PM, Bjoern Hoehrmann wrote:

> * Tab Atkins Jr. wrote:
> >Disclaimer: I'm a CSSWG member, was previously a web developer by
> >trade (now am a webkit engineer/spec author), and was only vaguely
> >aware of XPath a week ago.
>
> XPath support has been available in web browsers for over decade. If you
> have so far been unaware of it, that likely means you rarely if ever run
> into problems where XPath offers a good solution, and have basically no
> insight into the community that does. I on the other hand regularily run
> into such problems.
>
> Just this weekend I wrote an MP3 player. It hosts a web browser for the
> user interface to make it easy to adjust it for people who are familiar
> with technologies implemented by web browsers. One feature it has is na-
> vigation through the playlist using arrow keys. You have a track that is
> currently selected, "up" should go to the previous track, "down" to the
> next one, in playlist order.
>
> While there were various initiatives to standardize focus navigation in
> 2006 if I recall correctly, they have not quite materialized yet, so it
> takes scripting to implement this. Tracks in the playlist are table rows
> and so pressing "up" should move the cursor to the single node that is
> the previous table row from the perspective of the current one. That is
>
>  var previous = current.selectSingleNode("previous::tr")
>

Most people would accomplish that using jQuery. Something like:

var previous = $(current).closest("tr").prev()

I'm not exactly sure what `current` is in this case. What edge-cases are
you worried about when you say that the JavaScript is "quite involved"?


>
> as it has been available in Internet Explorer for over a decade. There
> is no Selectors equivalent and the JavaScript code for this is rather
> involved. There is also no proposal for Selectors extensions, or Java-
> script or DOM or whatever extensions to make this considerably easier.
> Yes, those could be implemented, that argument is from the 1990s and it
> does not really result in actual implementations.
>
> Also note in particular that you can read the code above even without
> knowing anything about XPath and yet you will fully understand from the
> context it is used in what it does. It is how code should be written.
>
> >In the recent discussions about XPath, I keep hearing a particular
> >theme that I believe is untrue, namely that XPath and Selectors
> >address different use-cases.  For example, Liam recently sent an email
> >containing the following:
> >
> >"XPath selectors give a different way of looking at finding things than
> >CSS selectors and probably appeal in differing amounts to different
> >people."
> >
> >"XPath has different goals from CSS selectors, and there's not actually a
> >battle between them."
> >
> >Neither of these are true.  The second could have been defended as
> >true several years ago, but not today.  I will defend my statement,
> >and then make the further argument that, due to the two being
> >identical, it is a bad idea to develop both of them.
>
> If you are actually interested in discussing why some people have some
> need for good XPath support, then it would be helpful if you could cut
> down on the rhetoric. If you make this about what is "true", then you
> are likely to create dynamics in the discussion that are unhelpful, in-
> cluding that people assume you care mostly about revealing The Truth,
> and don't actually care about views that differ from your own.
>
> I note that I find the first quote quite accurate and important, but I
> doubt you can actually appreciate how turning your thoughts into XPath
> syntax is different from turning them into Selectors syntax with no ex-
> perience in actually using XPath, in addition to you being a man on a
> mission. Add that you have chosen to express yourself in a manner that
> actively discourages discourse, I won't bother to try.
>
> >Both Selectors and XPath take some arbitrary notion of "nodes" with
> >certain aspects and a tree structure and, starting from the set of all
> >relevant nodes, repeatedly filter and transform the set until arriving
> >at a result.  They both do this in effectively identical ways; this
> >isn't like some concept of "turing equivalence" which can easily be
> >meaningless.
>
> No.
> --
> Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>
>

Re: [XHR] chunked

[Charles Pritchard]

On Nov 30, 2011, at 11:32 AM, Jonas Sicking  wrote:

>> Charles asked whether "chunked-text" was really needed (and whether we
>> should have "chunked" which implies ArrayBuffer instead). Nobody got back to
>> him on that.
> 
> Any text based format would benefit from chunked-text. While the
> example above uses a binary format, it applies equally to text based
> formats. And given how much we in this group seem to prefer text based
> formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
> assume that other people at least use them, if not prefer them.

My thinking was that ArrayBuffer can easily be converted to String by authors. 
Even with text-based formats, I prefer to fetch data as blob and buffer.


> 
>> If it is needed, how does it work when you just have some of
>> the bytes of a multi-byte character in a single chunk? Fails to decode as
>> per the normal algorithm?
> 
> Any multi-byte characters which are only partially downloaded are not
> returned in that "chunk". I.e. you only expose fully decoded
> characters. The value in progressEvent.loaded doesn't match up with
> the accumulated xhr.response.length for multi-byte encodings anyway.


This is an interesting case and may be a good reason to have a chunked text 
type.

When I'm parsing streams, I'm going to be waiting on various delimiters, and 
appending unprocessed bits... So the multibyte issue won't be an issue for me. 
Consider in any XML format, the developer is going to be seeking closing tags, 
or such.

But, getting the behavior you're looking for, where the callback is ensured 
that the string has full multibyte characters, that's not particularly easy for 
developers. While I wouldn't use it, as I'd use chunked arraybuffer, I can see 
how it'd be useful to achieve those parameters. There are various APIs that 
expect valid DOMString.

[Bug 14352] Event handler IDL attributes need [TreatNonCallableAsNull]

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14352

Jonas Sicking  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14408] [IndexedDB] Cursors .key/.primaryKey/.value shouldn't throw as soon as .continue is called

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14408

Jonas Sicking  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Jonas Sicking  2011-11-30 20:11:24 UTC ---
Fixed. Cursors now keep their value until a new value is loaded, or the cursor
iterates off the end.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14985] Specify how autoincrement + empty keypath works

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14985

Jonas Sicking  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Jonas Sicking  2011-11-30 20:10:44 UTC ---
Fixed, made it throw.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: XPath and Selectors are identical, and shouldn't be co-developed

[Bjoern Hoehrmann]

* Tab Atkins Jr. wrote:
>Disclaimer: I'm a CSSWG member, was previously a web developer by
>trade (now am a webkit engineer/spec author), and was only vaguely
>aware of XPath a week ago.

XPath support has been available in web browsers for over decade. If you
have so far been unaware of it, that likely means you rarely if ever run
into problems where XPath offers a good solution, and have basically no
insight into the community that does. I on the other hand regularily run
into such problems.

Just this weekend I wrote an MP3 player. It hosts a web browser for the
user interface to make it easy to adjust it for people who are familiar
with technologies implemented by web browsers. One feature it has is na-
vigation through the playlist using arrow keys. You have a track that is
currently selected, "up" should go to the previous track, "down" to the
next one, in playlist order.

While there were various initiatives to standardize focus navigation in
2006 if I recall correctly, they have not quite materialized yet, so it
takes scripting to implement this. Tracks in the playlist are table rows
and so pressing "up" should move the cursor to the single node that is
the previous table row from the perspective of the current one. That is

  var previous = current.selectSingleNode("previous::tr")

as it has been available in Internet Explorer for over a decade. There
is no Selectors equivalent and the JavaScript code for this is rather
involved. There is also no proposal for Selectors extensions, or Java-
script or DOM or whatever extensions to make this considerably easier. 
Yes, those could be implemented, that argument is from the 1990s and it
does not really result in actual implementations.

Also note in particular that you can read the code above even without
knowing anything about XPath and yet you will fully understand from the
context it is used in what it does. It is how code should be written.

>In the recent discussions about XPath, I keep hearing a particular
>theme that I believe is untrue, namely that XPath and Selectors
>address different use-cases.  For example, Liam recently sent an email
>containing the following:
>
>"XPath selectors give a different way of looking at finding things than
>CSS selectors and probably appeal in differing amounts to different
>people."
>
>"XPath has different goals from CSS selectors, and there's not actually a
>battle between them."
>
>Neither of these are true.  The second could have been defended as
>true several years ago, but not today.  I will defend my statement,
>and then make the further argument that, due to the two being
>identical, it is a bad idea to develop both of them.

If you are actually interested in discussing why some people have some
need for good XPath support, then it would be helpful if you could cut
down on the rhetoric. If you make this about what is "true", then you
are likely to create dynamics in the discussion that are unhelpful, in-
cluding that people assume you care mostly about revealing The Truth,
and don't actually care about views that differ from your own.

I note that I find the first quote quite accurate and important, but I
doubt you can actually appreciate how turning your thoughts into XPath
syntax is different from turning them into Selectors syntax with no ex-
perience in actually using XPath, in addition to you being a man on a
mission. Add that you have chosen to express yourself in a manner that
actively discourages discourse, I won't bother to try.

>Both Selectors and XPath take some arbitrary notion of "nodes" with
>certain aspects and a tree structure and, starting from the set of all
>relevant nodes, repeatedly filter and transform the set until arriving
>at a result.  They both do this in effectively identical ways; this
>isn't like some concept of "turing equivalence" which can easily be
>meaningless.

No.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

[Bug 14441] Note in IDBIndex.getKey is incorrect

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14441

Eliot Graff  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #1 from Eliot Graff  2011-11-30 19:56:40 
UTC ---
These notes are gone as of the Editors' Draft of 30 November.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 14735] [IndexedDB] Add multientry attribute to IDBIndex

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14735

Eliot Graff  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #2 from Eliot Graff  2011-11-30 19:55:57 
UTC ---
This is now in the Editors' Draft of 30 November.

Thanks!

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: [XHR] chunked

[Jonas Sicking]

On Wed, Nov 30, 2011 at 7:28 AM, Anne van Kesteren  wrote:
> A while ago sicking proposed adding chunked support to XMLHttpRequest:
>
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
> https://bugzilla.mozilla.org/show_bug.cgi?id=687087
>
> A use case I remember was downloading a large file of some kind that
> presumably can be incrementally rendered as otherwise responseType "blob"
> should be sufficient. More use cases appreciated. Would help with the
> design.

Incremental rendering as well as incremental parsing. Imagine for
example a webapp like google docs but with the ability to read MS-Word
documents directly client-side (currently I believe google docs does
their MS-Word file parsing server-side).

Even if the application wouldn't want to render the document right
away, parsing it incrementally rather than after the full download has
several advantages. First of all, external resources referenced from
the document can be loaded immediately and in parallel with the main
document. Second not having to keep the unparsed data of the full
document can save a bunch of memory. Third, it means that the document
is available for use sooner after the download is finished since most
if it is already parsed.

> Charles asked whether "chunked-text" was really needed (and whether we
> should have "chunked" which implies ArrayBuffer instead). Nobody got back to
> him on that.

Any text based format would benefit from chunked-text. While the
example above uses a binary format, it applies equally to text based
formats. And given how much we in this group seem to prefer text based
formats, (HTML, CSS, Javascript, EventSource, JSON) I think we should
assume that other people at least use them, if not prefer them.

> If it is needed, how does it work when you just have some of
> the bytes of a multi-byte character in a single chunk? Fails to decode as
> per the normal algorithm?

Any multi-byte characters which are only partially downloaded are not
returned in that "chunk". I.e. you only expose fully decoded
characters. The value in progressEvent.loaded doesn't match up with
the accumulated xhr.response.length for multi-byte encodings anyway.

> Also, this basically makes it possible to write EventSource on top of
> XMLHttpRequest. Is that acceptable? If it encourages more people to use a
> lower-level API, higher-level optimizations for mobile phones might become
> harder down the road.

It seems more than acceptable to me! It's a good sign if our low-level
primitives, like XHR, are extended to the point that they can be used
to implement our higher level APIs. That shows that we're building our
low-level primitives correctly.

And note that EventSource is already implementable on top of XHR. The
only thing that "chunked" is buying us is less memory usage.

But I also think that EventSource still has some significant
advantages in that it supplies things like automatic reconnection and
possibly in the future events delivered over SMS or other "push"
mechanisms.

/ Jonas

Re: XPath and find/findAll methods

[Liam R E Quin]

On Tue, 2011-11-29 at 18:09 +0200, Henri Sivonen wrote:
> On Tue, Nov 29, 2011 at 7:33 AM, Liam R E Quin  wrote:
> > (2) Not a dead end
[...]

Thanks for responding, Henri.

A detailed reply follows, but the short answer is -
(1) yes, browsers could be using the latest XPath. It would help authors
greatly.
(2) yes, there are some issues to resolve. The way to resolve issues is
liaison, and working together.  We should do more of that.
(3) the example I gave can in fact work in an XPath 2 environment.
(4) Backwards Compatibility Mode is probably rather badly named; just as
HTML has legacy content, so does XSLT.

This is why I suggest that, if a findAll() is introduced that can do
languages other than CSS Selectors, it allow a version number, with the
meaning, "I'm expecting at least this version of the language". Then one
could write code, if necessary to fall back, maybe downloading emulation
code in JavaScript if e.g. CSS selectors 5 or XPath 4 or whatever wasn't
available.

None of this is a reason not to make the existing XPath in Web browsers
easier to use today, though. I felt I needed to post to balance things a
bit because the status of XPath seemed unclear to some people on the
list.

Slightly more detailed reply...

> Sure, XPath and XSLT keep being developed. What I meant by
> evolutionary dead end is that the XPath 1.0-compatibile evolutionary
> path has been relegated to a separate mode instead of XPath 2.0 and
> newer being compatible by design.So the new development you cite
> happens with Compatibility Mode set to false. 

We can't change history, the compatibility mode is about compatibility
e.g. with pre-existing XSLT 1 stylesheets.  I don't see HTML 5 adding
the canvas element to RFC 1866 (HTML 2) either - and wouldn't expect it.
Just as you don't expect people working on Mosaic or Cello to need new
features in the HTML 2 spec, we're not adding new features to XPath 1,
because we already did that and called it XPath 2 :-)

Rather, the XPath spec is careful to document the differences in
behaviour.

We should really get rid of callign it compatibility mode and have
specific feature tests instead -- it'd be a lot clearer.  The main
differences are
* XPath 2 introduces sequences, so you can have sequences of arbitrary
values, not just nodelists; the empty sequence is returned in some cases
where it makes sense but Xath 1 used NaN or silently failed in some
other way; this could be a "sequence-available" feature.

* XPath 2 introduced named typing, rather like the C Programming
Language - e.g. a sockSize can be treated differently from a shoeSize
even though they are both numeric. Amongst other things, this allows a
saner interpretation of A = B, in the case that A and B are xs:boolean.
Although these are factored out into compatibility mode, in fact, they
are mostly cases that could never arise in XPath 1, as it didn't have
the typing system, so we could probably merge them rather than having a
type-system-available feature test.

* a number of error cases now raise errors instead of either failing or
doing an obviously wrong thing.  E.g. if $n is a nodelist of 3
paragraphs having content "11", "2", and "3" respectively, in XPath 1,
$n + 6 gives 17, and in XPath 2 it gives an error. But a Web browser
could plausibly use the XPath 1 behaviour and also emit a warning in the
developer console I think.

* XPath 2 allows implementations much more freedom in rearranging
evaluation order, greatly improving performance.

* there are some other minor changes listed in appendix I of the current
XPath 2.0 draft [1]. Most of these result in errors, so a browser could
easily allow them and produce helpful warnings. E.g. "1 < $a < 6" will
always be true, if $a is numeric, in XPath 1 (it's evaluated left to
right and you get 0 or 1 for "1 < $a"), and is an error in XPath 2.

* there are some changes to do with DTD and Schema handling that do not
affect Web browsers.

Frankly the differences are probably comparable to differences between
versions of HTML or editions of CSS -- the later specs get more precise,
and in the case of ambiguities or weird corner cases sometimes it means
a change.  The HTML 5 parsing goal was that all browsers would produce
the same DOM for a given document, and since that wasn't true
previously, some documents clearly now generate a different DOM.


> I don't have enough data about existing XPath-using Web content to
> know how badly the Web would break if browsers started interpreting
> existing XPath (1.x) expressions as XPath 2.x expression with
> Compatibility Mode set to false, but the fact that the WG felt that it
> needed to define a compatibility mode suggests that the WG itself
> believed the changes to be breaking ones.

They are breaking in a sense - the culture of the XML Activity is to be
very detailed and increasingly precise, so yes, there _are_ possible
XPath expressions which changed meaning.

The answer to this is not to avoid any spec that changes, as that would

Re: Enable compression of a blob to .zip file

[Charles Pritchard]

On 11/30/2011 8:04 AM, Julian Reschke wrote:

On 2011-11-30 16:50, Charles Pritchard wrote:
Nope. If you need gzipped SVG in data URIs, the right thing to do is 
to either extend data URIs to support that, or to mint a separate 
media type.


Why? Seems like a lot of complexity for blob, data and file for 
something that could otherwise be handled by minimal code.


It would mean that the semantics of a data URI depends on who's 
processing it. It would probably also cause lots of confusion about 
what types is applies to.


It's already the case that data URIs depend on UA quirks.
SVG support is highly implementation dependent.

This issue would apply to one type, SVG.
It's feature detectable through img src events.

This would greatly improve the ability to use data:uris for SVG content.
SVG can be highly compressible.

There's been a 9 years of lingering bug reports area:

https://bugzilla.mozilla.org/show_bug.cgi?id=157514
https://bugs.webkit.org/show_bug.cgi?id=5246
http://www.ietf.org/mail-archive/web/pkix/current/msg27507.html
http://lists.w3.org/Archives/Public/www-svg/2011May/0128.html
http://code.google.com/p/chromium/issues/detail?id=76968

There are all sorts of reasons to do it. It's a constant bummer that we 
need to include inflate code just to use inline svgz.

This issue also comes up with Blob.

It could have been fixed with the most minor of patches, years ago. I 
think that there are some theoretical purity issues here that have 
really things held-back.


I don't need to revise the entire data: uri, I'm just looking to add a 
note for content-type sniffing of the first few bytes of a file, when 
SVG is loaded

from a non-http resource, explicitly, file:, filesystem:, blob: and data:.

-Charles

Re: TAG Comment on

[Arthur Barstow]

Noah - FYI, I updated [Action-640] to include the TAG's comment [LC-2] 
(it originally was only for Ashok's personal comment [Ashok]) and 
updated LC-2 to connect it to Action-640.


-AB

[Action-640] http://www.w3.org/2008/webapps/track/actions/640
[LC-2] 
http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2
[Ashok] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0837.html


On 11/18/11 10:44 AM, ext Noah Mendelsohn wrote:
> Noah - the TAG's comment has been added to the comment tracking 
document

> for this LC:
>
> 
http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2


Thank you.

Noah

On 11/18/2011 10:01 AM, Arthur Barstow wrote:

Noah - the TAG's comment has been added to the comment tracking document
for this LC:

http://www.w3.org/2008/webapps/wiki/WebStorage-Comments-LC-25Oct2011#LC-2 



If anyone wants to propose extensions or changes to Web Storage, 
please use

[Bugzilla] and please feel free to contribute to the group's [Database]
wiki e.g. to clarify the relationship between Web Storage and HTML5's
AppCache.

If you have any additional feedback, please reply by November 25, the 
day

the CfC to publish a Candidate Recommendation of Web Storage ends [CfC].

-Art Barstow

[Bugzilla]
http://www.w3.org/Bugs/Public/describecomponents.cgi?product=WebAppsWG
[Database] http://www.w3.org/2008/webapps/wiki/Database
[CfC] 
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0998.html


On 11/15/11 5:05 PM, ext Noah Mendelsohn wrote:

This is a comment from the W3C Technical Architecture Group on the last
call working draft: "Web Storage" [1].

The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both
provide client-side storage that can be used by Web Applications.
Although the interfaces are different (AppCache has an HTML interface
while Local Storage has a JavaScript API), and they do seem to have 
been
designed with different use cases in mind, they provide somewhat 
related

facilities: both cause persistent storage for an application to be
created, accessed and managed locally at the client. If, for 
example, the

keys in Local Storage were interpreted as URIs then Local Storage could
be used to store manifest files and Web Applications could be 
written to
look transparently for manifest files in either the AppCache or in 
Local
Storage. One might also envision common facilities for querying the 
size

of or releasing all of the local storage for a given application.

At the Offline Web Applications Workshop on Nov 5, 2011 [3] there was a
request for a JavaScript API for AppCache and talk about coordinating
AppCache and Local Storage.

The TAG believes it is important to consider more carefully the 
potential

advantages of providing a single facility to cover the use cases, of
perhaps modularizing the architecture so that some parts are shared, or
if separate facilities are indeed the best design, providing common 
data

access and manipulation APIs. If further careful analysis suggests that
no such integration is practical, then, at a minimum, each 
specification

should discuss how it is positioned with respect to the other.

Noah Mendelsohn
For the: W3C Technical Architecture Group

[1] http://www.w3.org/TR/2011/WD-webstorage-20111025/
[2] http://www.w3.org/TR/html5/offline.html#appcache
[3] http://www.w3.org/2011/web-apps-ws/

Re: Enable compression of a blob to .zip file

[Julian Reschke]

On 2011-11-30 16:50, Charles Pritchard wrote:

Nope. If you need gzipped SVG in data URIs, the right thing to do is to either 
extend data URIs to support that, or to mint a separate media type.


Why? Seems like a lot of complexity for blob, data and file for something that 
could otherwise be handled by minimal code.


It would mean that the semantics of a data URI depends on who's 
processing it. It would probably also cause lots of confusion about what 
types is applies to.


Best regards, Julian

Re: Enable compression of a blob to .zip file

[Charles Pritchard]

On Nov 30, 2011, at 7:05 AM, Julian Reschke  wrote:

> On 2011-10-31 20:20, Charles Pritchard wrote:
>> On 10/31/11 11:34 AM, Boris Zbarsky wrote:
>>> On 10/31/11 1:42 PM, Charles Pritchard wrote:
 I'm almost certain that somewhere, it is specified that the browser
 should sniff the first few bytes of the file to see
 if it is compressed.
>>> 
>>> I don't believe it is. In fact, doing that would contradict the specs
>>> as they stand, to my knowledge.
>>> 
>>> I could be wrong, of course, but in that case citation needed...
>>> 
>>> -Boris
>>> 
>> Well I've failed to find a citation. I will post one if I find it.
>> 
>> In the meantime: Blob and Data uris can and should have sniffing for
>> image/svg+xml.
>> ...
> 
> Nope. If you need gzipped SVG in data URIs, the right thing to do is to 
> either extend data URIs to support that, or to mint a separate media type.

Why? Seems like a lot of complexity for blob, data and file for something that 
could otherwise be handled by minimal code.

[XHR] chunked

[Anne van Kesteren]

A while ago sicking proposed adding chunked support to XMLHttpRequest:

http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
https://bugzilla.mozilla.org/show_bug.cgi?id=687087

A use case I remember was downloading a large file of some kind that  
presumably can be incrementally rendered as otherwise responseType "blob"  
should be sufficient. More use cases appreciated. Would help with the  
design.


As for the feature, basically have responseType "chunked-text" and  
"chunked-arraybuffer" values and reset rather than update the response  
entity body with each progress event. And make sure that a progress event  
is dispatched when the last fetch event is queued. And make sure that this  
is only available for asynchronous usage.


Charles asked whether "chunked-text" was really needed (and whether we  
should have "chunked" which implies ArrayBuffer instead). Nobody got back  
to him on that. If it is needed, how does it work when you just have some  
of the bytes of a multi-byte character in a single chunk? Fails to decode  
as per the normal algorithm?


Also, this basically makes it possible to write EventSource on top of  
XMLHttpRequest. Is that acceptable? If it encourages more people to use a  
lower-level API, higher-level optimizations for mobile phones might become  
harder down the road.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Enable compression of a blob to .zip file

[Julian Reschke]

On 2011-10-31 20:20, Charles Pritchard wrote:

On 10/31/11 11:34 AM, Boris Zbarsky wrote:

On 10/31/11 1:42 PM, Charles Pritchard wrote:

I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed.


I don't believe it is. In fact, doing that would contradict the specs
as they stand, to my knowledge.

I could be wrong, of course, but in that case citation needed...

-Boris


Well I've failed to find a citation. I will post one if I find it.

In the meantime: Blob and Data uris can and should have sniffing for
image/svg+xml.
...


Nope. If you need gzipped SVG in data URIs, the right thing to do is to 
either extend data URIs to support that, or to mint a separate media type.


Best regards, Julian

Re: Enable compression of a blob to .zip file

[Julian Reschke]

On 2011-10-31 18:42, Charles Pritchard wrote:

On 10/30/2011 5:56 PM, Cameron McCormack wrote:

On 30/10/11 4:25 PM, Bjoern Hoehrmann wrote:

Then he probably means file system files and not HTTP files, and support
there has indeed been spotty in the past.


Ah, yes. Regarding data: URIs, someone should really just amend the
RFC to allow specifying a content encoding.


That'll be tricky with respect to backwards compatibility; but it could 
be worth a try.



That seems rather unnecessary.

I'm almost certain that somewhere, it is specified that the browser
should sniff the first few bytes of the file to see
if it is compressed. It's minimal work.

This also applies to the local file system; as in file:///.


Hm, no. It's not specified, and seems like a bad idea to do.

Best regards, Julian

CfC: publish new WD of XHR; deadline December 5

[Arthur Barstow]

Anne completed his merge XHR and XHR2 merge and the new History section 
includes information about the merge. As such, this is a Call for 
Consensus to publish a new WD of XHR using the following ED (not yet 
"pub ready") as the basis:


  http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html

Agreement to this proposal: a) indicates support for publishing a new 
WD; and b) does not necessarily indicate support of the contents of the WD.


If you have any comments or concerns about this proposal, please send 
them to public-webapps by December 5 at the latest.


As with all of our CfCs, positive response is preferred and encouraged 
and silence will be assumed to be agreement with the proposal.


-AB

Re: Enable Compression Of A Blob To .zip File

[Joran Greef]

It would be great to have a native binding to Zlib and Snappy exposed to 
Javascript in the browser. Zlib covers the expensive disk use-cases, Snappy 
covers the expensive CPU use-cases.

Also a native binding to basic crypto primitives, even if that means just SHA1 
to start, and even if the Node.js crypto api is copied verbatim.

TypedArrays are in current implementations are too slow to help with these, as 
far as I have tried.

Re: Enable compression of a blob to .zip file

[Paul Bakaus]

Fyi - it's been a long time request from Zynga to have a web packaging
format to serve and store assets in large chunks. A relevant ticket with a
discussion can be found here:
https://bugzilla.mozilla.org/show_bug.cgi?id=681967

I'm all for it, of course.

Am 31.10.11 12:20 schrieb "Charles Pritchard" unter :

>On 10/31/11 11:34 AM, Boris Zbarsky wrote:
>> On 10/31/11 1:42 PM, Charles Pritchard wrote:
>>> I'm almost certain that somewhere, it is specified that the browser
>>> should sniff the first few bytes of the file to see
>>> if it is compressed.
>>
>> I don't believe it is.  In fact, doing that would contradict the specs
>> as they stand, to my knowledge.
>>
>> I could be wrong, of course, but in that case citation needed...
>>
>> -Boris
>>
>Well I've failed to find a citation. I will post one if I find it.
>
>In the meantime: Blob and Data uris can and should have sniffing for
>image/svg+xml.
>
>It's trivial, and it makes a whole lot more sense than extending both
>the Blob and data uri specs to include transfer encoding semantics.
>file: and filesystem: and widget urls are items that -might- be
>supported on an OS level, and thus out of scope here.
>
>Back to deflate use cases: PDF.js I'm sure implements deflate (for PDF
>FlateEncode), I've recently done some docx work which required deflate.
>Many servers do not host .svgz files well, and I use XHR with deflate to
>deal with that (though I would have just used blob urls if they worked).
>localStorage, indexedDB and WebSQL all require DOMString, as do most
>WebSocket implementations -- in practical use, this means base64
>encoding data. It's another area where deflate could squeeze a few more
>bytes out of existing constraints. Especially with localStorage.
>
>As we continue to support more-and-more document formats, deflate
>support on the client side becomes more important. Apple and MS, two
>very large vendors, have pushed ahead with using deflate in various file
>formats they use. Adobe has been doing it for some time.
>
>Though HTTP works quite well for negotiated compression there are more
>and more cases that are not http bound. I would very much like to see
>deflate and inflate exposed to the scripting environment. From there I
>can easily interact with several file formats. Zip included.
>
>-Charles
>
>
>-Charles
>
>
>
>