[WebIDL] Sequences and arrays
Hello WG. I’ve finally fixed up sequences in Web IDL, and also added an array type. The difference is that: * sequences are effectively pass-by-value, represented by a JS Array or a Java array object, and * arrays are pass-by-reference, represented by a JS host object that acts similarly to an Array (including having Array.prototype in its prototype chain, but not supporting sparse arrays) or by a Java object that implements an interface defined in the spec that allows access to elements and the array length. JS Array objects can also be passed to host objects expecting an array, but the Array object will be converted into the special host object. http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence http://dev.w3.org/2006/webapi/WebIDL/#idl-array http://dev.w3.org/2006/webapi/WebIDL/#es-sequence http://dev.w3.org/2006/webapi/WebIDL/#es-array http://dev.w3.org/2006/webapi/WebIDL/#java-sequence http://dev.w3.org/2006/webapi/WebIDL/#java-array Comments welcome. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Sequences and arrays
Only one comment:
it should be noted that with
interface Example {
sequencelong numbers;
}
In EcmaScript ex.numbers != ex.numbers, because each access to
numbers creates a new Array
This is probably counterintuitive to most users of the interface and
may prevent many uses of sequence as attributes (to avoid such
confusion).
Giovanni
2009/7/7 Cameron McCormack c...@mcc.id.au:
Hello WG.
I’ve finally fixed up sequences in Web IDL, and also added an array
type. The difference is that:
* sequences are effectively pass-by-value, represented by a JS Array
or a Java array object, and
* arrays are pass-by-reference, represented by a JS host object that
acts similarly to an Array (including having Array.prototype in its
prototype chain, but not supporting sparse arrays) or by a Java
object that implements an interface defined in the spec that allows
access to elements and the array length.
JS Array objects can also be passed to host objects expecting an array,
but the Array object will be converted into the special host object.
http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
http://dev.w3.org/2006/webapi/WebIDL/#idl-array
http://dev.w3.org/2006/webapi/WebIDL/#es-sequence
http://dev.w3.org/2006/webapi/WebIDL/#es-array
http://dev.w3.org/2006/webapi/WebIDL/#java-sequence
http://dev.w3.org/2006/webapi/WebIDL/#java-array
Comments welcome.
--
Cameron McCormack ≝ http://mcc.id.au/
re: [widgets] Rule for Parsing a Non-negative Integer
Accidentally forgot to send to public-webapps. -- Forwarded message -- From: Marcos Caceres marc...@opera.com Date: Wed, Jul 1, 2009 at 12:28 PM Subject: Re: [widgets] Rule for Parsing a Non-negative Integer To: Anne van Kesteren ann...@opera.com 2009/6/10 Anne van Kesteren ann...@opera.com: The algorithm itself deals with leading and trailing spaces. The additional requirement about them makes matters confusing. Please remove it. Removed A user agent must ignore leading and trailing space characters. -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Comments on Widgets 1.0: Packaging and configuration, 9.1 Processing rules
Hi all, sorry I didn't jump in earlier, I was taken with entirely different considerations. François is entirely right in his evaluation of the way in which widget URIs work, which is to say that in a document at the root of the widget you can't treat a href='/foo' and a href='foo' any different. Or at least, not without deciding that we have our own rules for relative URI reference absolutisation, which I fervently hope we don't. I think that there are two ways to resolve this comment: - drop the distinction that's in the spec between /foo and foo in config.xml - make it very clear that that distinction exists only in config.xml (which uses paths, not URIs) Since I don't personally see a strong use case for the distinction, I'm happy either way. Technically I have a small preference for the first option, process-wise I prefer the clarification. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
RE: [widgets] conformance requirements review
Le dimanche 05 juillet 2009 à 18:50 +0200, Marcin Hanclik a écrit : Just FYI I created a tool to check the BONDI specs under: http://bondi01.obe.access-company.com/ It automatically checks each new release of the BONDI specs directly from the SVN repository. Very nice! Would it be possible to share the source code of these tools, so that both WebApps and DAP participants could re-use and extend them to fit their needs? Dom
Re: [widgets] Comments on Widgets 1.0: Packaging and configuration, 9.1 Processing rules
On Tue, Jul 7, 2009 at 2:43 PM, Robin Berjonro...@berjon.com wrote: Hi all, sorry I didn't jump in earlier, I was taken with entirely different considerations. François is entirely right in his evaluation of the way in which widget URIs work, which is to say that in a document at the root of the widget you can't treat a href='/foo' and a href='foo' any different. Yes, I understand that. Or at least, not without deciding that we have our own rules for relative URI reference absolutisation, which I fervently hope we don't. I think we all agree we want URIs to behave as they do in browsers. I think that there are two ways to resolve this comment: - drop the distinction that's in the spec between /foo and foo in config.xml I'm ok to do this. It now reads: If the path starts with a U+002F SOLIDUS (e.g., /style/master.css), meaning that the path is an Zip absolute path, then remove the first U+002F SOLIDUS from path. The algorithm continues as normal (i18n is applied, etc.) and no longer is the behavior different (i.e., the root of the widget package is not searched first, but last). So, this means that the behavior of both /abc and abc are now exactly the same. - make it very clear that that distinction exists only in config.xml (which uses paths, not URIs) If they are paths or not depends on the processing model. But yes, the current model assumes paths. Since I don't personally see a strong use case for the distinction, I'm happy either way. I do see strong need to sort this out. It might be that in the future, for whatever reason, we want to treat these as URIs. For example, allowing cont...@src to point to a document on the Web. Technically I have a small preference for the first option, process-wise I prefer the clarification. My preference is that everything be treated as a URI. However, because the current model treats the values as paths, the model is incomplete. To treat the value of zip paths as URIs, they need to be converted to URI strings. _HOWEVER_, we can deal with this in the future. Lets agree that this is the way it's going to work for now. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] conformance requirements review
Hi Dom, Responses inline... As before, for the sake of the Disposition of Comments, please let us know if you are satisfied with the responses below. On Wed, Jun 17, 2009 at 10:04 AM, Dominique Hazael-Massieuxd...@w3.org wrote: Hi, I wrote a simple XSLT to extract the conformance requirements from the Widgets spec [1], with the following output: http://www.w3.org/2005/08/online_xslt/xslt?xslfile=http%3A%2F% 2Fdev.w3.org%2F2006%2Fwaf%2Fwidgets%2Ftests% 2FextractTestAssertions.xslxmlfile=http%3A%2F%2Fcgi.w3.org%2Fcgi-bin% 2Ftidy-if%3FdocAddr%3Dhttp%253A%252F%252Fwww.w3.org%252FTR%252Fwidgets% 252F Based on these, here is a review of the Widgets spec based on conformance requirements analysis: * ideally, only the classes of products would appear as subjects of the conformance requirements; e.g. A folder may contain zero or more file entries or zero or more folders would be rephrased as A valid widget package may contain folders with zero or more file entries or zero or more folders; FWIW, I added the above... this would have two benefits: simplify the analysis of conformance requirements for building test suites, and identify possible ambiguities as to what is affected when the conformance requirements is not respected; that said, I don't think it is crucial so feel free to not go through all the conformance requirements if that's too much work We have agreed to do this in CR. These would be editorial changes, albeit really important ones! * similarly, conformance requirements that use the passive voice are suspect (since they often don't tell to which class they apply) As above. * For sniffing the content type of images formats, a user agents must use the rule for Identifying the media type of an image - this assumes that the user agent already knows the file it is sniffing is an image; Yes, the UA knows it is sniffing and image because of the context (this rule is only ever used for icons). if that's true, the text should make it clear why, and if not, it should probably be reworded to say that a user agent must sniff for images format first I've removed the following assertions as they were misleading: [[ As there is no notion of a media type within Zip, a user agent must perform file-extension to media-type mapping, followed by content-type sniffing, in order to determine the media type of a file. For sniffing the content type of images formats, a user agent must use the rule for Identifying the media type of an image. For other file formats, a user agent must use the rule for Identifying the media type of a file. ]] Sniffing of images and files is controlled by Step7. Step 7 always gives the context of what is being looked for (either a file or an image). To the Rule for Identifying the Media Type of an Image i've added the following note: [[ Note:This rule is only to be applied when explicitly instructed to by the specification (during Step 7). ]] * rather than say Reserved file names must be treated as case-sensitive, I would amend the previous sentence to say The reserved file names table, below, contains a *case-sensitive* list... (and similarly for folder names) Done. * If [...] the start file is not one that is supported by a particular user agent, then the CC must inform the author: does that mean that a CC need to know all the supported formats by all user agents? That seems a bit excessive - I guess I can see cases where a conformance checker could be configured to report knowledge on a special user agent, but that would need to be made explicit, and clearly shouldn't be a must * a widget may attempt to access the feature identified by the feature element's name attribute I think the may here is not intended as a conformance requirement, so it probably shouldn't be marked as such Used can instead of MAY * there is a spurious empty em class=ct/em element in A feature canem class=ct/em have zero or more a href=#parameter0 title=parameterparameters/a associated with it. Fixed. * The steps for processing a widget package involves nine steps that a user agent SHOULD follow ; the should appear in upper case in the source, while other conformance requirements are lower case fixed. * a user agent must to decompress is not correct English fixed * If a user agent encounters an unusable file entry, it must ignore the file entry: is ended by a colon, but followed by a new sentence Fixed. * The algorithm always returns a string, which may be empty: again, this may doesn't look like a conformance requirement so shouldn't be marked as such Fixed. * that must eventually be presented to the end-user - I don't think this is meant as a conformance requirement (e.g. a conformance checker is a user agent, but will probably never present any of the widget content to the end-user); I would reword it as to be presented to the end user Fixed. Used your text. * an error condition can ask the user agent ignore an
Re: [widgets] conformance requirements review
Le mardi 07 juillet 2009 à 20:11 +0200, Marcos Caceres a écrit : Responses inline... As before, for the sake of the Disposition of Comments, please let us know if you are satisfied with the responses below. I'm satisfied, thanks. Dom
Re: [webstorage] Ambiguous Requirement for Key Ordering
On Tue, 9 Jun 2009, Lachlan Hunt wrote: The spec states [1]: The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object between changes to the number of keys. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) There is an ambiguity that can make that paragraph self-contradictory, depending on how the phrase [the order] must be consistent within an object between changes to the number of keys.. The ambiguity appears to be caused by the use of the word between in that context. I initially interpreted that as meaning that the order must remain consistent when the number of keys changes. But then this interpretation is contradicted by the parenthetical sentence following it. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Berkeley DB license (was Re: Points of order on this WG)
On Fri, Jun 26, 2009 at 5:36 PM, Maciej Stachowiakm...@apple.com wrote: On Jun 26, 2009, at 3:46 PM, Nikunj R. Mehta wrote: FWIW, I came across two pieces about Oracle's open source licensing of Berkeley DB that might help clear the air around the licensing issues. First, Oracle's license [1] is word-for-word identical to the erstwhile SleepyCat license [2]. Secondly, SleepyCat license qualifies as a free software license, and is compatible with the GNU General Public License. [3]. Thirdly, the license is OSI approved [4]. I am not sure if this resolves issues. It would help if you had comments on the above so that I can keep that in my context while discussing with our legal staff. The issue I see with using Berkeley DB for implementation (which I think is only a side issue to design of the spec itself) is as follows: Clause 3 of the first license (the one with the Oracle copyright notice) appears to have stricter source release requirements than LGPL. It's not clear to me what exactly the scope of the requirement is, but it doesn't seem to have the dynamic linking or relinkable object file exceptions of LGPL. That would be a problem for projects like WebKit or Gecko that don't want to impost any constraints that go beyond the LGPL in their license terms. Probably speaking out of turn, but on the larger point that there are non-BDB implementations that are well suited for the browser environment. For example, Tokyo Cabinet is a C library for B-tree databases, licensed under the LGPL. http://tokyocabinet.sourceforge.net/spex-en.html TC is far from the only clearly licensed storage-engine with lots of users. Any of them (including BDB) would make a good foundation for implementing a CouchDB-like replication system in JavaScript. As a web-developer I would really get a lot out of serious native B-tree API. The nice thing is that a B-tree API is so simple it'd be easy for vendors to use any number of engines and still achieve the same spec. Chris I don't want to start a huge debate over this, I just wanted to clarify the issue I see. Regards, Maciej -- Chris Anderson http://jchrisa.net http://couch.io
Re: [WebIDL] Sequences and arrays
Giovanni Campagna:
Only one comment:
it should be noted that with
interface Example {
sequencelong numbers;
}
In EcmaScript ex.numbers != ex.numbers, because each access to
numbers creates a new Array
This is probably counterintuitive to most users of the interface and
may prevent many uses of sequence as attributes (to avoid such
confusion).
Yes that’s a good point. I’ve added such a note:
http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
pointed it out in the ECMAScript sequence example:
http://dev.w3.org/2006/webapi/WebIDL/#es-sequence
and added the concept of a “read only” array:
http://dev.w3.org/2006/webapi/WebIDL/#dfn-read-only-array
In the added note I suggest to use read only arrays instead of sequences
for attribute types.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
