[Bug 14364] appcache: Add an API to make appcache support caching specific URLs dynamically
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364 Simon Pieters sim...@opera.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER | --- Comment #8 from Simon Pieters sim...@opera.com 2011-11-04 06:16:57 UTC --- (In reply to comment #7) I have marked this LATER so that we can look add this once browsers have caught up with what we've specified so far. I believe this has already happened. -- 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: innerHTML in DocumentFragment
On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren ann...@opera.com wrote: On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda wants a way of parsing where you do not know the context in advance. This is something I've always wanted, so I always wrote my piece of code to make the task easier. But I do suggest a different solution: Instead of # var f = document.createDocumentFragment() # f.innerHTML = '...'; which is quite verbose, I would suggest a simpler API, like # var document_fragment_node = parseFragment(markup_fragment, Node contextNode, boolean safe); # var element_node = parseNode(markup_fragment, Node contextNode, boolean safe); # var document_node = parseDocument(markup_fragment, boolean safe); * markup_fragment is the html string, or xml depending on the type of document of the ownerDocument of contextNode. * contextNode is an Element for parsing context and to know the ownerDocument, or if context is not important, the Document which will be the ownerDocument of the resulting fragment * stripScripts is a boolean that tells the parser to strip unsafe content like scripts, event listeners and embeds/objects which would be handled by a 3rd party plugin according to user agent policy. - parseFragment parses a markup fragment which may not have a single root element, hence having siblings, with context. - parseFragment parses a markup fragment which must have a single root element, so the DocumentFragment can be spared. This is usually the most wanted use case. - parseDocument similar to DOMParser but for html. At least for me, an API with these features are everything that I've ever needed. Thanks.
Re: Storage Quota API
(Sorry for replying to somewhat ancient thread) On Wed, Sep 28, 2011 at 1:43 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Sep 27, 2011 at 6:12 AM, Kinuko Yasuda kin...@chromium.org wrote: Just to confirm: Yes the interfaces are vendor prefixed (WebKit), and WebSQL, AppCache, IDB are treated as temporary in the current chromium implementation. On Tue, Sep 27, 2011 at 8:53 AM, Charles Pritchard ch...@jumis.com wrote: Any ideas on how to express temp v. Perm to IndexedDB? IIRC there's been a proposal to have a way to hint that an IndexedDB ObjectStore is 'evictable' or not: http://www.w3.org/Bugs/Public/show_bug.cgi?id=11350 Though it seems to be put off until later (version 2), I was assuming that once we have the 'evictable' option it would indicate the data's Temp/Perm attribute. Other storage APIs do not have a way to express temp/perm either. Chromium's current policy is defaulting to conservative or less astonishment to the users (in our belief), so that they won't see unexpected prompts or unknown data pressing their disk space. And instead getting unexpected data loss :) I agree that no way to persist data in the offline storage wouldn't be great and could result in bad user experience, but given the fact that most of offline data storage is used as a kind of 'cache' and that the webapp can easily detect if its data is lost or not I wonder if data loss in a (supposedly sandboxed) webapp would be that critical... or am I missing some important usage? Another concern: if we allow webapps to store data persistently by default users will need to have some nice UI for adjusting quota / deleting app data per app especially when the storage is being pressed or in an environment where storage is inherently limited (e.g. phones). Also even with such nice UI I doubt majority of users would want to manage their storage (for webapps) in that detail. What do you think about this? How is Gecko trying to solve the UI / management issue? (By the way... is there a plan to revive the 'evictable' flag anytime soon? Either one of 'all temporary' or 'all persistent' discussion might sound a bit too extreme.) Also if we want to make this API as a spec should the default storage type for each storage API be included in the spec (either in the quota one or in each API spec)? Quota has been a minor but headaching issue around web offline solution for some time. Maybe we could try making things a bit clearer based on what we've agreed / come up with so far? Thanks, / Jonas
[Bug 14694] New: innerHTML in DocumentFragment
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14694 Summary: innerHTML in DocumentFragment Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DOM Parsing and Serialization AssignedTo: ms2...@gmail.com ReportedBy: ms2...@gmail.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0663.html -- 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: Spec changes for LCs and later maturity levels
On 11/3/11 5:16 PM, ext Peter Saint-Andre wrote: On 11/3/11 8:28 AM, Anne van Kesteren wrote: On Thu, 03 Nov 2011 08:07:20 -0700, Julian Reschke julian.resc...@gmx.de wrote: Reminder: this was a past-LC change. I think I'm not asking too much when I'm asking for a precise explanation of what the rational for this change was. As I explained already, we moved processing requirements from the protocol to the API. Round and round we go, where it stops nobody knows. :) It seems there are two topics here: 1. The procedural issue of moving the text from the protocol spec to the API document. I have no opinion about this. The group discussed this on October 31 [1]. The gist of the agreement is that since the text that is now in the API spec used to be in the protocol spec, the totality of a review of the two specs is effectively the same. In this view, the change to the API spec is not substantive. 2. The substantive issue of whether the text is correct. Julian asked some questions about that, and I'd be curious to see replies (especially because they are related to similar topics in HTML5). I think we need to continue to move forward and to acknowledge several implementations of the API spec have been deployed. As such, I tend to think we may have already passed the point of diminishing returns regarding minor tweaks to the spec and if there are bugs, in the spec, please file bugs and we can address them during CR. -AB [1] http://www.w3.org/2011/10/31-webapps-minutes.html#item14
Re: Spec changes for LCs and later maturity levels
On 2011-11-04 17:10, Arthur Barstow wrote: ... The group discussed this on October 31 [1]. The gist of the agreement is that since the text that is now in the API spec used to be in the protocol spec, the totality of a review of the two specs is effectively the same. In this view, the change to the API spec is not substantive. ... Doesn't compute. The text was *removed* from the protocol spec because the WG found it to be misleading (suggesting WS URIs are different from other URIs). It was *not* removed because we thought it belongs somewhere else. Also, in case that wasn't clear, it was *replaced* by different text. 2. The substantive issue of whether the text is correct. Julian asked some questions about that, and I'd be curious to see replies (especially because they are related to similar topics in HTML5). I think we need to continue to move forward and to acknowledge several implementations of the API spec have been deployed. As such, I tend to think we may have already passed the point of diminishing returns regarding minor tweaks to the spec and if there are bugs, in the spec, please file bugs and we can address them during CR. ... Right now, the spec uses an algorithm without actually referring to it. A *minimal* fix is to make that a proper reference. Best regards, Julian
Re: Spec changes for LCs and later maturity levels
On Fri, 04 Nov 2011 09:18:29 -0700, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-04 17:10, Arthur Barstow wrote: The group discussed this on October 31 [1]. The gist of the agreement is that since the text that is now in the API spec used to be in the protocol spec, the totality of a review of the two specs is effectively the same. In this view, the change to the API spec is not substantive. ... Doesn't compute. The text was *removed* from the protocol spec because the WG found it to be misleading (suggesting WS URIs are different from other URIs). It was *not* removed because we thought it belongs somewhere else. Also, in case that wasn't clear, it was *replaced* by different text. Citation needed. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0640.html I think we need to continue to move forward and to acknowledge several implementations of the API spec have been deployed. As such, I tend to think we may have already passed the point of diminishing returns regarding minor tweaks to the spec and if there are bugs, in the spec, please file bugs and we can address them during CR. ... Right now, the spec uses an algorithm without actually referring to it. A *minimal* fix is to make that a proper reference. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0661.html -- Anne van Kesteren http://annevankesteren.nl/
Re: innerHTML in DocumentFragment
Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? Daniel On Fri, Nov 4, 2011 at 05:54, João Eiras jo...@opera.com wrote: On Fri, 04 Nov 2011 00:48:29 +0100, Anne van Kesteren ann...@opera.com wrote: On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down timd...@gmail.com wrote: Have you looked at the createContextualFragment() method of Range? http://html5.org/specs/dom-**parsing.html#dom-range-** createcontextualfragmenthttp://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment That requires a context. Yehuda wants a way of parsing where you do not know the context in advance. This is something I've always wanted, so I always wrote my piece of code to make the task easier. But I do suggest a different solution: Instead of # var f = document.**createDocumentFragment() # f.innerHTML = '...'; which is quite verbose, I would suggest a simpler API, like # var document_fragment_node = parseFragment(markup_fragment, Node contextNode, boolean safe); # var element_node = parseNode(markup_fragment, Node contextNode, boolean safe); # var document_node = parseDocument(markup_fragment, boolean safe); * markup_fragment is the html string, or xml depending on the type of document of the ownerDocument of contextNode. * contextNode is an Element for parsing context and to know the ownerDocument, or if context is not important, the Document which will be the ownerDocument of the resulting fragment * stripScripts is a boolean that tells the parser to strip unsafe content like scripts, event listeners and embeds/objects which would be handled by a 3rd party plugin according to user agent policy. - parseFragment parses a markup fragment which may not have a single root element, hence having siblings, with context. - parseFragment parses a markup fragment which must have a single root element, so the DocumentFragment can be spared. This is usually the most wanted use case. - parseDocument similar to DOMParser but for html. At least for me, an API with these features are everything that I've ever needed. Thanks.
Re: innerHTML in DocumentFragment
On Fri, Nov 4, 2011 at 9:33 AM, Daniel Cheng dch...@chromium.org wrote: Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? If I understand your suggestion correctly, then no, that would mean that Yehuda's original example: var frag = document.createDocumentFragment(); frag.innerHTML = trtdhello/td/tr someTable.appendChild(frag) would break - the frag would end up with a table and tbody inside, which is wrong when you then try to insert it into an existing table. ~TJ
Re: Spec changes for LCs and later maturity levels
On 2011-11-04 17:36, Anne van Kesteren wrote: On Fri, 04 Nov 2011 09:18:29 -0700, Julian Reschke julian.resc...@gmx.de wrote: On 2011-11-04 17:10, Arthur Barstow wrote: The group discussed this on October 31 [1]. The gist of the agreement is that since the text that is now in the API spec used to be in the protocol spec, the totality of a review of the two specs is effectively the same. In this view, the change to the API spec is not substantive. ... Doesn't compute. The text was *removed* from the protocol spec because the WG found it to be misleading (suggesting WS URIs are different from other URIs). It was *not* removed because we thought it belongs somewhere else. Also, in case that wasn't clear, it was *replaced* by different text. Citation needed. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0640.html I pointed you to the thread on the HyBi mailing list that caused the change to happen (starting at https://www.ietf.org/mail-archive/web/hybi/current/msg07377.html). The WG discussed the topic, I was asked to propose text, and the editor adopted it. As far as I recall, there was no further discussion. (that's how IETF WGs normally operate) I think we need to continue to move forward and to acknowledge several implementations of the API spec have been deployed. As such, I tend to think we may have already passed the point of diminishing returns regarding minor tweaks to the spec and if there are bugs, in the spec, please file bugs and we can address them during CR. ... Right now, the spec uses an algorithm without actually referring to it. A *minimal* fix is to make that a proper reference. http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0661.html You open the two dependencies, do a full text search, and you are done. If you think that's sufficient then please have that text added to the spec, pointing out it applies to things that might be names of algorithms and which are marked up in bold (right?). Personally, I don't think this is acceptable. Editorial glitches like this happen, and that's ok, but that doesn't mean it's ok to leave them in a published spec when the problem is discovered beforehand. Best regards, Julian
[Bug 14695] How do I clear browsing history automatically? Is there a setting in Google Chrome, like I.E. to clear cookies and websites visited, etc. to clear everything automatically upon exiting C
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14695 Tab Atkins Jr. jackalm...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jackalm...@gmail.com Resolution||INVALID --- Comment #1 from Tab Atkins Jr. jackalm...@gmail.com 2011-11-04 17:12:11 UTC --- This is not a technical support forum. -- 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.
File API: Determining encoding
Questions and thoughts while reading http://dev.w3.org/2006/webapi/FileAPI/#enctype: What does cannot determine the encoding mean in step 1? Does that mean if the UA doesn't support the encoding? If not, is this spec actually requiring that every registered encoding be supported? It's odd that decoding and reencoding a valid Unicode blob doesn't round-trip, since any BOM is removed during decoding. Leaving them in would cause its own problems, though... It would be clearer if steps 1 and 2 used the same terminology for an invalid character set. In step 1, the encoding parameter is declared invalid in prose beforehand, and then its validity is checked in step 1. In step 2, there's no invalid intermediary and it's simply checked directly. The flow of the steps is odd. Step 1 says decode the Blob and terminate this set of steps, but that will cause step 6 to not be executed. Step 2 says [otherwise] go to the next step, but it never says to do otherwise (there's no terminate this set of steps beforehand). I think this should look more like: When reading blob objects using the readAsText() read method, the following encoding determination steps MUST be followed: 1. Let charset be null. 2. If the encoding parameter is specified, and is the name or alias of a character set used on the Internet [IANACHARSET], let charset be encoding parameter. 3. If charset is null, and the blob's type attribute is present, and its Charset Parameter [RFC2046] is the name or alias of a character set used on the Internet, let charset be its Charset Parameter. 4. If charset is null, then for each of the rows in the following table, starting with the first one and going down, if the first bytes of blob match the bytes given in the first column, then let charset be the encoding given in the cell in the second column of that row. [table] 5. If charset is null, let charset be UTF-8. 6. Return the result of decoding ... -- Glenn Maynard
Re: innerHTML in DocumentFragment
In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Daniel On Fri, Nov 4, 2011 at 09:45, Tab Atkins Jr. jackalm...@gmail.com wrote: On Fri, Nov 4, 2011 at 9:33 AM, Daniel Cheng dch...@chromium.org wrote: Instead of simply switching the insertion mode when you see an element that doesn't belong in in-body mode for context-less parsing, would it make sense to synthesize the appropriate context elements instead? If I understand your suggestion correctly, then no, that would mean that Yehuda's original example: var frag = document.createDocumentFragment(); frag.innerHTML = trtdhello/td/tr someTable.appendChild(frag) would break - the frag would end up with a table and tbody inside, which is wrong when you then try to insert it into an existing table. ~TJ
Re: innerHTML in DocumentFragment
2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ
Re: innerHTML in DocumentFragment
On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Daniel
Re: innerHTML in DocumentFragment
Sent from my iPhone On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote: On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Isn't that an argument for changing the in-body insertion mode, or perhaps creating a new insertion mode for contenteditable? Daniel
Re: innerHTML in DocumentFragment
On Fri, Nov 4, 2011 at 12:15, Yehuda Katz wyc...@gmail.com wrote: Sent from my iPhone On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote: On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Isn't that an argument for changing the in-body insertion mode, or perhaps creating a new insertion mode for contenteditable? Daniel I don't think it's an argument for changing in-body insertion mode, since it feels like a return to the tag soup days of HTML. And simply making contenteditable special doesn't help either--what if you have a read-only view of the data? Daniel
Re: innerHTML in DocumentFragment
My use-cases all want pure DOM nodes with no extra cruft added, because they assume insertion into proper containers. This is true about both jQuery and future updates to template content inserted in the DOM. For the use case of give me nodes that I can insert into a regular context and then serialize, perhaps a different API is in order? Sent from my iPhone On Nov 4, 2011, at 12:44 PM, Daniel Cheng dch...@chromium.org wrote: On Fri, Nov 4, 2011 at 12:15, Yehuda Katz wyc...@gmail.com wrote: Sent from my iPhone On Nov 4, 2011, at 11:55 AM, Daniel Cheng dch...@chromium.org wrote: On Fri, Nov 4, 2011 at 11:19, Tab Atkins Jr. jackalm...@gmail.com wrote: 2011/11/4 Daniel Cheng dch...@chromium.org: In that example, there was a clear context element though--I'd argue that Range.createContextualFragment should have been used instead. It seems like the general use of such a function would be to add some nodes from a snippet of HTML markup into a div for example, where synthesizing the correct context elements would make more sense. Sorry, I referred only to Yehuda's first example for simplicity. Please read the rest of Yehuda's first post, as his later examples both (a) break (or at least become unnecessarily difficult) if contextual wrappers are automatically added, and (b) don't have a context element to apply at the time the DOM is being constructed. I see. I think I understand this particular use case and why contextual wrappers would make it harder. If one is adding nodes into a div, one would *not* write: var frag = parse(trtdfoo/tr) div.appendFragment(frag); ...because that would be nonsensical. In particular, jQuery does *not* do anything special when they see this sort of pattern - they go to some effort to ensure that the fragment contains only the tr and descendants, and then would directly insert it into the DOM as a child of the div. ~TJ That being said, why is it non-sensical? If I were writing a rich text editor that accepted pastes or allowed drag and drop editing, it seems like a perfectly reasonable thing to create a fragment from the markup and then insert it at the appropriate point. I originally suggested synthesizing wrappers because if a page ended up serializing and saving potentially invalid markup, then it might not render properly later. You could, of course, argue that the appropriate context nodes should have been present in the markup to begin with. Isn't that an argument for changing the in-body insertion mode, or perhaps creating a new insertion mode for contenteditable? Daniel I don't think it's an argument for changing in-body insertion mode, since it feels like a return to the tag soup days of HTML. And simply making contenteditable special doesn't help either--what if you have a read-only view of the data? Daniel
CfC: Identifying Test Spec Editors; deadline Nov 11
Hi All, One of the topics discussed this week was to designate a Test Spec Editor(s) for each of our specs. One reason to identify Test Spec Editors is to acknowledge that some Spec Editors don't have the cycles to lead their spec's testing effort and another is to try to prevent the proverbial fox guarding the chicken coop problem i.e. it may be better/preferred for someone other than the Spec Editor to lead the testing of their spec. If you have any comments, please send them by November 11. In the absence of strong negative feedback, I propose we introduce this role and I will separately issue some type of Call for Test Spec Editors for our specs. (BTW, the title of Test Spec Editor is a bit of a straw-man, so proposals for other titles are also welcome.) -Thanks, AB
