Obsolescence notices on old specifications, again
Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Colliding FileWriters
On Sun, Jan 22, 2012 at 7:10 AM, Glenn Maynard gl...@zewt.org wrote:
On Sun, Jan 22, 2012 at 12:57 AM, Jonas Sicking jo...@sicking.cc wrote:
myFileEntry.createWriter(function(mywriter) {
// write some data
mywriter.write(someblob);
// wait for success
mywriter.onwrite = function() {
// Read some data;
reader = new FileReader;
reader.readAsArrayBuffer(mywriter.file);
// wait for success
reader.onload = function() {
// do something with read data
}
};
});
This is pretty hideous though, but as far as I can tell better than
what we have now. But it is very surprising to have a File accessor on
the FileWriter.
Is the above meant to lock myFileEntry for the entire operation, starting
when the function(mywriter) callback starts and ending with reader.onload?
Yes. How exactly it works is something that is being discussed in this
very thread. The idea discussed so far is to have an explicit
FileWriter.close() call which would release the lock. The lock would
also be released when the FileWriter is GCed.
think the main problem is that reading and writing is spread out
over two separate objects. I can't think of a way to make things look
good as long as that is the case. Maybe the solution is to add
readAsArrayBuffer/readAsText/readAsDataURL directly on FileWriter?
Could FileWriter inherit from FileReader (and FileWriterSync from
FileReaderSync)?
That wouldn't make much sense since FileWriter is tied to a specific
file, whereas the functions on FileReader is passed the file to read
as an argument.
There's an underlying issue to this, though. It only allows a single object
to access the file. (Putting read access on FileWriter--turning it into
something like FileReadWriter--is just a workaround for that issue.) This
could bite the platform later on; it doesn't allow any other API that
accesses File data to coexist and use the same locking mechanism.
The more familiar approach would be to lock Entry (analogous to locking the
file itself), and then allowing any API to access the Entry in that thread.
This is definitely an interesting idea.
/ Jonas
Re: Colliding FileWriters
On Mon, Jan 23, 2012 at 4:02 AM, Jonas Sicking jo...@sicking.cc wrote: Yes. How exactly it works is something that is being discussed in this very thread. The idea discussed so far is to have an explicit FileWriter.close() call which would release the lock. The lock would also be released when the FileWriter is GCed. That'd expose GC behavior, though. Having a function called that locks during the call and unlocks when it returns would be fine, but wouldn't work with the async API at all. If the lock was associated with the Entry, then the GC exposure would be reduced, but not eliminated. You would lose the lock at the same time you lost the Entry itself, so the thread that grabbed the lock wouldn't see GC behavior (barring multiple Entries for the same file). However, any other threads waiting on that lock would still see the GC if they're waiting on the lock. I suppose the lock could be retained until you return to the event loop without any reads or writes in progress on the FileWriter, but that's a little magic and easy to get wrong (eg. a setTimeout in the async call chain would cause you to lose the lock). That wouldn't make much sense since FileWriter is tied to a specific file, whereas the functions on FileReader is passed the file to read as an argument. I hadn't noticed that. That's an unfortunate inconsistency... -- Glenn Maynard
Re: CfC: to add Speech API to Charter; deadline January 24
On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote: Some of the reasons we believe that the JavaScript Speech API is best suited for WebApps, instead of it's own working group, include: 1. Speech is likely to become a core API, like other WebApps deliverables such as File API. It is important that it be compatible and consistent with, and interact well with other JavaScript API components. Agreed. 2. WebApps provides a balanced web-centric view for new JavaScript APIs. The XG group consisted of a large number of speech experts, but only a few with broad web API expertise. We believe the formation of a new WG would have a similar imbalance, I'm not sure this is necessarily the case, and the reverse possibility, that the Web Apps group would not have enough speech experts should also be considered a potential risk. whereas the WebApps WG can provide valuable, balanced guidance and feedback. (FWIW I don't have a strong opinion on whether this is likely to be a real problem as opposed to a risk, and I think this conversation helps us work that out). 3. The scope of this effort is well-defined and bounded. All that have responded to this CfC have agreed that JavaScript API portions of the XG Final Report are relevant to WebApps, and that the wire protocol portions of the XG Final Report are not relevant to WebApps (and should be pursued in another group, such as IETF). I think that's a fair summary The differing opinions seem only about the specific starting point of this effort, whether to base it on the full JavaScript API in the XG's Final Report [1] or a subset of that JavaScript API, which supports the majority of use cases, as proposed by Google [2]. Or a subset that supports a majority of use cases as currently proposed by Debbie, developed by whittling down from [1] based on what implementors are prepared to do. For this first recommendation-track document, we believe a subset will accelerate implementation, interoperability testing, standardization and ultimately developer adoption. However, in the spirit of consensus, we are willing to broaden this subset to include additional API features in the XG Final Report. That makes sense. We do think that it is important to be working on stuff that gets implemented, as a good guide to what ends up in a recommendation and what's in the list for an expanded version. One point of the WG process is that we can have more than one input document, and we develop consensus as we go on what gets deployed and is therefore ripe for further formal standardisation, and what is still waiting... cheers Chaals [1] http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Bjorn Bringert Satish Sampath Glen Shires On Fri, Jan 20, 2012 at 3:58 AM, Arthur Barstow art.bars...@nokia.comwrote: The deadline for comments is extended to January *24*. On 1/20/12 6:55 AM, ext Arthur Barstow wrote: The deadline for comments is extended to January. Andrian, Maciej - I would appreciate it you would please provide some feedback on this CfC. On 1/12/12 7:31 AM, ext Arthur Barstow wrote: Glen Shires and some others at Google proposed [1] that WebApps add Speech API to WebApps' charter and they put forward the Speech Javascript API Specification [2] as as a starting point. Members of Mozilla and Nuance have voiced various levels of support for this proposal. As such, this is a Call for Consensus to add Speech API to WebApps' charter. Positive response to this CfC is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is January 19 and all comments should be sent to public-webapps at w3.org. -AB [1] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/1696.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1696.html [2] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/att-1696/speechapi.**htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: to add Speech API to Charter; deadline January 24
On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote: On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote: 2. WebApps provides a balanced web-centric view for new JavaScript APIs. The XG group consisted of a large number of speech experts, but only a few with broad web API expertise. We believe the formation of a new WG would have a similar imbalance, I'm not sure this is necessarily the case, and the reverse possibility, that the Web Apps group would not have enough speech experts should also be considered a potential risk. whereas the WebApps WG can provide valuable, balanced guidance and feedback. (FWIW I don't have a strong opinion on whether this is likely to be a real problem as opposed to a risk, and I think this conversation helps us work that out). Another way to help us get the broadest set of stakeholders possible is for the Speech work to be done in a new WG or an existing WG like with some speech experts (Voice Browser WG or MMI WG?) and then to create some type of joint task force with WebApps. This would have the advantage that WebApps members would only have to make an IP commitment for the specs created by the task force (and none of the other WG's specs) and the other WG would not have to make an IP commitment for any of WebApps' other specs. (Note we are already doing this for the Web Intents spec and the Dev-API WG). Is the VBWG or MMIWG interested in taking the lead on the speech spec? -AB
Re: Obsolescence notices on old specifications, again
I object to adding such notice until all of the proposed replacement specs reach REC status. G. On Mon, Jan 23, 2012 at 2:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/**Public/www-dom/2012JanMar/**0011.htmlhttp://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
I support adding warnings. As far as I know, all major browser vendors are using the more modern version of each of these specs for implementation work. That's certainly true for WebKit at least. It doesn't help anyone to look at outdated specs considering them to be the latest and greatest when the vast majority of implementations no longer match them. Ojan On Mon, Jan 23, 2012 at 10:06 AM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. G. On Mon, Jan 23, 2012 at 2:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/**Public/www-dom/2012JanMar/**0011.htmlhttp://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 12:06 PM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. Why? The real world of modern spec use and authoring is no longer tightly tied to reaching REC (or even CR or PR), and the current situation of outdated specs with no warnings, misleadingly presented as if they represent modern practice, repeatedly leads to both user and implementer confusion. I don't know if this is the right thing to do for all of the listed specs, but in general this is important to fix. -- Glenn Maynard
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 1:01 AM, Ms2ger ms2...@gmail.com wrote: Hi all, The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. Ms2ger [1] http://lists.w3.org/Archives/Public/www-dom/2012JanMar/0011.html I also strongly support adding warnings. There's little worse than spending time reviewing or even implementing a feature from a spec only to be told that it's obsolete, everyone else already knew that, and you just wasted a bunch of time. To answer Glenn's objection, many of the specs already have better and more functional replacements, regardless of their status in the W3C Process. Even if they don't, knowing that we consider a spec to be abandoned and obsolete is valuable - that way people can either work on a replacement, or figure out what was wrong with the original draft that causes us to abandon it and fix that. Omitting such a warning helps literally no one. ~TJ
RE: CfC: to add Speech API to Charter; deadline January 24
Hi Art, That's a very good point about IP commitments. I think it's likely to speed up the process of getting something standardized if companies don't have to make the broad IP commitments to all of a WG's activities that would be required if the work was entirely done within an existing WG. As far as existing Working Groups go, I think that the Voice Browser WG would be a better choice than the MMIWG, because the HTML-Speech work is focused on the details of a speech-specific API, which is the expertise of the Voice Browser WG. However, I think a new group would be better because the group could concentrate entirely on the HTML-Speech work and not have to prioritize it with other specs. Also, both VB and MMI are member-confidential, and it would be easier to work with a joint WebApps task force in a new, public, WG. Regards, Debbie -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Monday, January 23, 2012 12:39 PM To: ext Charles McCathieNevile; Glen Shires; Deborah Dahl; Scott McGlashan; Kazuyuki Ashimura Cc: public-webapps; public-xg-htmlspe...@w3.org Subject: Re: CfC: to add Speech API to Charter; deadline January 24 On 1/23/12 12:17 PM, ext Charles McCathieNevile wrote: On Fri, 20 Jan 2012 18:37:35 +0100, Glen Shires gshi...@google.com wrote: 2. WebApps provides a balanced web-centric view for new JavaScript APIs. The XG group consisted of a large number of speech experts, but only a few with broad web API expertise. We believe the formation of a new WG would have a similar imbalance, I'm not sure this is necessarily the case, and the reverse possibility, that the Web Apps group would not have enough speech experts should also be considered a potential risk. whereas the WebApps WG can provide valuable, balanced guidance and feedback. (FWIW I don't have a strong opinion on whether this is likely to be a real problem as opposed to a risk, and I think this conversation helps us work that out). Another way to help us get the broadest set of stakeholders possible is for the Speech work to be done in a new WG or an existing WG like with some speech experts (Voice Browser WG or MMI WG?) and then to create some type of joint task force with WebApps. This would have the advantage that WebApps members would only have to make an IP commitment for the specs created by the task force (and none of the other WG's specs) and the other WG would not have to make an IP commitment for any of WebApps' other specs. (Note we are already doing this for the Web Intents spec and the Dev-API WG). Is the VBWG or MMIWG interested in taking the lead on the speech spec? -AB
Re: Obsolescence notices on old specifications, again
I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. G. On Mon, Jan 23, 2012 at 12:09 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Jan 23, 2012 at 12:06 PM, Glenn Adams gl...@skynav.com wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. Why? The real world of modern spec use and authoring is no longer tightly tied to reaching REC (or even CR or PR), and the current situation of outdated specs with no warnings, misleadingly presented as if they represent modern practice, repeatedly leads to both user and implementer confusion. I don't know if this is the right thing to do for all of the listed specs, but in general this is important to fix. -- Glenn Maynard
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. But really, the important thing is just that these specs are hurting the web, and our primary focus is the web. ~TJ
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Jan 23, 2012 at 12:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I do not object to adding an informative, warning notice to the status sections of these docs that new work is underway to replace, and eventually formally obsolete older DOM RECs. However, until replacement specs exist that have achieved sufficient maturity (namely, REC status), it would not be appropriate to formally obsolete the existing DOM specs. We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. But really, the important thing is just that these specs are hurting the web, and our primary focus is the web. In my opinion, the poor progress (in terms of time) in obtaining closure on new specs (i.e., reaching REC status) is doing more harm than keeping mature specs on the book. Furthermore, the industry I work in is not something outside the web, but is part of the web. It is just a part of the web that tends to evolve more slowly, and, consequently, assigns more priority to creating and maintaining formally mature specs.
Re: Obsolescence notices on old specifications, again
Tab, Le 23 janv. 2012 à 22:03, Tab Atkins Jr. a écrit : We have repeated evidence that pretending these specs aren't obsolete and useless hurts web implementors and authors. We're targeting the web with our specs, so that's extremely relevant for us, more so than non-web industries dealing with personal regulatory issues. I personally agree that developers need to be directed to the latest spec. Some warning should be there. But a person outside the W3C should not be expected to be taken to some draft document for its implementation. The word obsolete about a spec that has no REC-status replacement really gives outsiders the impression that the whole thing is obsolete (there would be no recommendation of the W3C for my purpose? I thought they did). Another formulation needs to be found, even something such as about to be obsoleted. Ignoring the regulatory issues for a moment, the non-web industries harm themselves (or rather, the down-level authors writing content for the things those industries are producing) by attempting to use these obsolete specs as well, since they'll be producing things that don't match the public web. To my personal taste this feels in line with the craze of running after the latest update all the times. The way Chrome does it without warning you and Firefox screams to update to a new version every other month has the reasons to destabilize people! How can I be sure that my neighbours' website is going to play tomorrow? (he doesn't follow the latest trends yet, he'll learn) A good example of such craze is the Flash player: no RECs here, just one proprietary implementation. Flash upgrades have killed old deployments! Adobe or MacroMedia can't be blamed... no promise was made, no standard was declared to be followed (at least recently). paul
Re: Testing Expectations (was: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization)
On Thu, 12 Jan 2012 17:06:34 +0100, Doug Schepers schep...@w3.org wrote: As such, the creation of tests should not be left to CR... there should be a plan in place (e.g. a person, and a loose policy, like as we implement, we'll make tests and contribute them to the WG), and a person responsible for collecting and maintaining the tests (i.e. making sure that the tests are adapted to meet the changing spec). Indeed, we agreed recently that this would be something we require in any work the group takes on... So rather than warm fuzzies, we're really after a warm body to take responsibility for driving it. cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan litt norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
[indexeddb] Missing TransactionInactiveError Exception type for count and index methods
In looking at the count method in IDBObjectStore and IDBIndex we noticed that its signature doesn't throw a TransactionInactiveError when the transaction being used is inactive. We would like to add this to the spec. In addition, the index method in IDBObjectStore uses InvalidStateError to convey two different meanings: the object has been removed or deleted and the transaction being used finished. It seems that it would be better to separate these into: * InvalidStateError when the source object has been removed or deleted. * TransactionInactiveError when the transaction being used is inactive. What do you think? I can open a bug if we agree this is the desired behavior. Thanks, Israel
Re: Obsolescence notices on old specifications, again
* Ms2ger wrote: The recent message to www-dom about DOM2HTML [1] made me realize that we still haven't added warnings to obsolete DOM specifications to hopefully avoid that people use them as a reference. If you want to say more than that the specifications are no longer being maintained and which newer specifications might contain more recent de- finitions for the features covered you will have to create a process for that first (it would require Advisory Committee review for instance, as otherwise you are likely to create unnecessary drama). I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) As far as I am aware, CSSOM is an unmaintained and incomplete set of ideas, and what of it reflects actually implemented behavior and what may change tomorrow is anyone's best guess so that is clearly not a suitable replacement. DOM4 fails to define many widely implemented features and makes many backwards-incompatible changes, I don't see how someone who wants to im- plement the DOM in Java would use the draft rather than the Recommen- dations as a starting point, especially not now as it's rather unclear how much consensus behind all the various proposed changes is outside a rather narrow group of people around the draft's editors. It's a stretch to call it a specification at all, it's more like a reference implemen- tation in an ad-hoc assembly language that's not very useful for people who are not Web browser DOM implementation maintainers. If you want to know if setAttributeNS changes the namespace prefix, you go to the DOM Level 3 Core specification which will tell you If an attribute with the same local name and namespace URI is already present on the element, its prefix is changed ... as the second sentence; you don't go to DOM4 and debug the code there to combine the facts that it sets `prefix` to a certain value in step #4, does not change it in the steps 5-9, and then does not use the value in step ten, into the conclusion that unless you missed some subtlety in the code, or the many definitions it relies on, that it does not change it. And a reviewer is unlikely to even notice the proposal would change the behavior. The proposal pretends that .createElement creates elements in the XHTML namespace. That is not what all current browsers do, it's not what non- browser implementations currently do, and probably not what they should do or are likely to do in the future. So how does that help people who do not already know about DOM4 and would not use DOM Level 2 Core as a reference anyway? For DOM Level 2 HTML the proposed alternative is indeed better at least in some regards like coverage, so a pointer would make some sense. and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation You will have to use the Rescinding process for that, and this would re- quire a legal analysis of the impact of rescinding the Recommendations (Validation does not seem to indicate under which Patent Policy it has been produced, and Load and Save was produced under the transitional rules; under the 2004 Patent Policy rescinding a Recommendation has im- plications on licensing requirements, and it is not clear to me whether people who wish to implement either specification in a year from now to replace some legacy product with backwards-compatibility would be worse off if the documents were rescinded). I also note that you have made no argument why these should be rescinded beyond perhaps that web browser developers might not want to implement it currently if they haven't already done so. That is not something to capture in the status of these documents. -- 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: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods
On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio isra...@microsoft.comwrote: In looking at the count method in IDBObjectStore and IDBIndex we noticed that its signature doesn't throw a TransactionInactiveError when the transaction being used is inactive. We would like to add this to the spec. Agreed. FWIW, this matches Chrome's behavior. In addition, the index method in IDBObjectStore uses InvalidStateError to convey two different meanings: the object has been removed or deleted and the transaction being used finished. It seems that it would be better to separate these into: * InvalidStateError when the source object has been removed or deleted. * TransactionInactiveError when the transaction being used is inactive. What do you think? I can open a bug if we agree this is the desired behavior. Did this come out of the discussion here: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html If so, the rationale for which exception type to use is included, although no-one on the thread was deeply averse to the alternative. If it's a different issue can give a more specific example?
Re: [Bug 15434] New: [IndexedDB] Detail steps for assigning a key to a value
There's another edge case here - what happens on a put (etc) request to an
object store with a key generator when the object store's key path does not
yield a value, yet the algorithm below exits without changing the value.
Sample:
store = db.createObjectStore(my-store, {keyPath: a.b, autoIncrement:
true});
request = store.put(value);
3.2.5 for put has this error case The object store uses in-line keys and
the result of evaluating the object store's key path yields a value and
that value is not a valid key. resulting in a DataError. In this case,
4.7 Steps for extracting a key from a value using a key path says no
value is returned, so that error case doesn't apply.
5.1 Object Store Storage Operation step 2 is: If store uses a key
generator and key is undefined, set key to the next generated key. If store
also uses in-line keys, then set the property in value pointed to by
store's key path to the new value for key.
Per the algorithm below, the value would not change. (Another example would
be a keyPath of length and putting [1,2,3])
Chrome's current behavior in this case is that the put (etc) call returns
without raising an error, but an error event is raised against the request
indicating that the value could not be applied. This would imply having the
algorithm below return a success/failure indicator and having the steps in
5.1 abort if the set fails.
Thoughts?
On Wed, Jan 11, 2012 at 4:36 PM, Israel Hilerio isra...@microsoft.comwrote:
Great! I will work with Eliot to unify the language and update the spec.
** **
Israel
** **
On Wednesday, January 11, 2012 3:45 PM, Joshua Bell wrote:
On Wed, Jan 11, 2012 at 3:17 PM, Israel Hilerio isra...@microsoft.com
wrote:
We updated Section 3.1.3 with examples to capture the behavior you are
seeing in IE.
** **
Ah, I missed this, looking for normative text. :)
** **
Based on this section, if the attribute doesn’t exists and there is an
autogen is set to true the attribute is added to the structure and can be
used to access the generated value. The use case for this is to be able to
auto-generate a key value by the system in a well-defined attribute. This
allows devs to access their primary keys from a well-known attribute. This
is easier than having to add the attribute yourself with an empty value
before adding the object. This was agreed on a previous email thread last
year.
I agree with you that we should probably add a section with “steps for
assigning a key to a value using a key path.” However, I would change step
#4 and add #8.5 to reflect the approach described in section 3.1.3 and #9
to reflect that you can’t add attributes to entities which are not
objects. In my mind this is how the new section should look like:
When taking the steps for assigning a key to a value using a key path, the
implementation must run the following algorithm. The algorithm takes a key
path
named /keyPath/, a key named /key/, and a value named /value/ which may be
modified by the steps of the algorithm.
1. If /keyPath/ is the empty string, skip the remaining steps and /value/
is
not modified.
2. Let /remainingKeypath/ be /keyPath/ and /object/ be /value/.
3. If /remainingKeypath/ has a period in it, assign /remainingKeypath/ to
be
everything after the first period and assign /attribute/ to be everything*
***
before that first period. Otherwise, go to step 7.
4. If /object/ does not have an attribute named /attribute/, then create
the attribute and assign it an empty object. If error creating the
attribute then skip the remaining steps, /value/ is not modified, and throw
a DOMException of type InvalidStateError.
5. Assign /object/ to be the value of the attribute named /attribute/ on**
**
/object/.
6. Go to step 3.
7. NOTE: The steps leading here ensure that /remainingKeyPath/ is a single
attribute name (i.e. string without periods) by this step.
8. Let /attribute/ be /remainingKeyPath/
8.5. If /object/ does not have an attribute named /attribute/, then create
the attribute. If error creating the attribute then skip the remaining
steps, /value/ is not modified, and throw a DOMException of type
InvalidStateError.
9. If /object/ has an attribute named /attribute/ which is not modifiable,
then
skip the remaining steps, /value/ is not modified, and throw a
DOMException of type InvalidStateError.
10. Set an attribute named /attribute/ on /object/ with the value /key/.**
**
What do you think?
** **
Overall looks good to me. Obviously needs to be renumbered. Steps 4 and
8.5 talk about first creating an attribute, then later then assigning it a
value. In contrast, step 10 phrases it as a single operation (set an
attribute named /attribute/ on /object/ with the value /key/). We should
unify the language; I'm not sure if
[Bug 14404] Version of an IDBDatabase from an aborted version change transaction needs to be specified
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14404 Jonas Sicking jo...@sicking.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from Jonas Sicking jo...@sicking.cc 2012-01-24 03:52:24 UTC --- The change made here is a bit unclear. The text says If the transaction is aborted and there is an existing database, the values remain unchanged. There's two things that are unclear here. By database you mean the IDBDatabase(Sync) instance, right? Not the on-file database. I think we should clarify that. Second, does remain unchanged mean unchanged compared to the on-disk values, or unchanged based on the values on the IDBDatabase instance before the transaction was aborted? Almost the same questions also applies to the text says that if the VERSION_CHANGE transaction used to create a database is aborted, that the database will remain in the system with the default attributes. Is database referring to the on-disk database or the IDBDatabase instance? I would have assumed that the on-disk database is simply deleted if the transaction that created it is aborted. I think I would prefer to not have any special treatment for VERSION_CHANGE transactions that create a database vs. ones that just upgrade the version number. This seems simplest from an implementation point of view. Also, there's the minor nit that aborting can happen outside of the upgradeneeded event handler too since the transaction can span multiple success and error events too. I would recommend something like the following text for step 9.5: If for any reason the VERSION_CHANGE transaction is aborted the IDBDatabase instance which represents varconnection/var will remain unchanged. I.e. it's codename/code, codeversion/code and codeobjectStoreNames/code properties will remain the value they were before the transaction was aborted. (Note that objectStoreNames per the IDL is never null, though it can be an empty list). -- Configure bugmail: https://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: Obsolescence notices on old specifications, again
On Mon, 23 Jan 2012, Glenn Adams wrote: I object to adding such notice until all of the proposed replacement specs reach REC status. I object to REC status, and support implementing Ms2ger's proposal forthwith. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [indexeddb] Missing TransactionInactiveError Exception type for count and index methods
On Mon, Jan 23, 2012 at 5:17 PM, Joshua Bell jsb...@chromium.org wrote: On Mon, Jan 23, 2012 at 4:12 PM, Israel Hilerio isra...@microsoft.com wrote: In looking at the count method in IDBObjectStore and IDBIndex we noticed that its signature doesn't throw a TransactionInactiveError when the transaction being used is inactive. We would like to add this to the spec. Agreed. FWIW, this matches Chrome's behavior. Same here. In addition, the index method in IDBObjectStore uses InvalidStateError to convey two different meanings: the object has been removed or deleted and the transaction being used finished. It seems that it would be better to separate these into: * InvalidStateError when the source object has been removed or deleted. * TransactionInactiveError when the transaction being used is inactive. What do you think? I can open a bug if we agree this is the desired behavior. Did this come out of the discussion here: http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1589.html If so, the rationale for which exception type to use is included, although no-one on the thread was deeply averse to the alternative. If it's a different issue can give a more specific example? Right. I think InvalidStateErr is better, for the reason detailed in the above referenced email. I agree we're using the same exception for two error conditions, but I'm not terribly worried that this will make debugging harder for authors. But I don't feel strongly so if there's a good reason I'm ok with changing things. / Jonas
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 5:58 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * Ms2ger wrote:I propose that we add a pointer to the contemporary specification to the following specifications: ... * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) ... As far as I am aware, CSSOM is an unmaintained and incomplete set of ideas, and what of it reflects actually implemented behavior and what may change tomorrow is anyone's best guess so that is clearly not a suitable replacement. As an FYI, the two CSSOM specs now have new co-editors, who are working towards publishing new WDs within the next month. On the other hand, this work contains innovations that remain immature and need further implementation activity and testing (as would be required by the normal maturation process in the W3C).
Re: Obsolescence notices on old specifications, again
On Mon, Jan 23, 2012 at 11:01 AM, Ms2ger ms2...@gmail.com wrote: I propose that we add a pointer to the contemporary specification to the following specifications: * DOM 2 Core (DOM4) * DOM 2 Views (HTML) * DOM 2 Events (D3E) * DOM 2 Style (CSSOM) * DOM 2 Traversal and Range (DOM4) * DOM 2 HTML (HTML) * DOM 3 Core (DOM4) and a recommendation against implementing the following specifications: * DOM 3 Load and Save * DOM 3 Validation Hearing no objections, I'll try to move this forward. I support adding such notices to the above-mentioned specs. On Mon, Jan 23, 2012 at 10:38 PM, Glenn Adams gl...@skynav.com wrote: I work in an industry where devices are certified against final specifications, some of which are mandated by laws and regulations. The current DOM-2 specs are still relevant with respect to these certification processes and regulations. I think proliferating obsolete stuff is harmful. Which laws or regulations require compliance with some of the above-mentioned specs? Have bugs been filed on those laws and regulations? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
