Re: [widgets] duplicated feature elements ?
Le 05/01/2010 21:13, Marcos Caceres a écrit : On Tue, Jan 5, 2010 at 8:50 PM, Marcos Caceresmarc...@opera.com wrote: On Wed, Dec 16, 2009 at 10:51 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi all, There is a test in the test suite for duplicated param element with the same name but different value (v9.wgt). But I did not find, a similar test for duplicated feature elements with the same name. Is this allowed or not ? The algorithm in Step 7 does not say. This is allowed. I've added the following note to make that clear (not checked into cvs yet): Note: This specification allows feature elements with the same name and/or value to be declared more than once. Handling of duplicate feature requests is left up to the implementation. I made a mistake above, it should have read: This specification allows feature elements with the same name attribute value to be declared more than once. Handling of duplicate feature requests is left up to the implementation. Fine, thanks. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] PC simplifying some rules (editorial)
Le 05/01/2010 23:29, Marcos Caceres a écrit : On Wed, Dec 9, 2009 at 1:50 PM, Cyril Concolatocyril.concol...@enst.fr wrote: Hi all, I noticed that 9.1.3. Rule for Finding a File Within a Widget Package indicates that the algorithm returns either a file, null, or an error.. This is not exactly true since if it does return an error or null, it always returns a processable file. Ok, clarified this in the spec (that is, returns a processable file instead of just a file) Fine. I suggest changing the introduction as follows The algorithm returns either a processable file, null, or an error. and then doing the following three edits: - Change point 7 in the license element in 9.1.15. Algorithm to Process a Configuration Document to indicate: If file is null or there is an error in 6 then ignore this element I don't agree with this change. The point already says: If file is not a processable file This implicitly means if file is null or in error or anything else. I agree. - Change the similar point for the icon element. As above. I agree. - Simplify Step 9 - Process the Default Icons by collapsing A.A, A.B and A.C into if potential icon is null or in error or already exists, ignore it The above is not precise enough for my liking, but it made sense to collapse it a given that a processable file is always returned... so, I've changed it to: If the potential-icon is a processable file, determined by the media type given in the media type column of the default icons table, and the potential-icon does not already exist in the icons list of the table of configuration defaults, then append the value of potential-icon to the icons list of the table of configuration defaults. It's a somewhat long sentence, but I can live with it... and it doesn't change what was already there. You're right it's a bit long but I'm also fine with it. Also, I was wondering for quite some time why the spec has a strange structure for Rules vs. Steps. Couldn't you put all the Rules into one section 9.1 and all the Steps in 9.2? Yeah, admittedly, it got a little messy wrt what defines a rule and what defines a step... that was me doing crazy literary experiments in the hope of making the spec easier to read and work with... I wanted to write rules like they were reusable functions, and the Steps as if they were independent parts of a program... not sure if I succeeded, but generally I get people saying they like the way I structured the spec... but have also been told it's confusing. So, you are probably correct that what is defined in Step 9 should have been a rule (and hence gone into 9.1). I don't think there is much point now in changing it, however. We should just be trying to squish any outstanding spec bugs (if any) and otherwise let it be... I was not saying that I don't like the separation between steps and rules. It's just the structure of Section 9 that I find weird. It's ok if you don't change the spec now. you can keep it in mind for a 2nd edition or a 1.1 version :) we still have a ton of work to do on updates and view modes, so I just want to call PC done and start oiling the gears to move it to Proposed Rec by the end of the month. Once GPAC and Widgeon are at 100%, we will have 5 conforming implementations which I think it's a pretty awesome achievement and a testament to the implement-ability of the spec. I agree, this proves that the spec and the test suite are both in good shapes. FYI, out of the 166 tests, GPAC fails 7 because of XML/Unicode handling. This will probably be fixed. 1 fails because we don't implement SNIFF. I don't know if we will. 3 fail because we don't maintain tables of supported mime types, encodings or features, at the level of the widget UA. I don't know yet how to fix that. The last failure is related to the handling of invalid feature elements, on which I disagree with the test suite (see next email). So hopefully, I should get close to the 100% in the future. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/widgets/
Re: [widgets] feature: inconsistent behavior ?
Le 05/01/2010 23:54, Marcos Caceres a écrit : On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Sorry, but it was a resolution that all correctly named features are considered required (it's why we had to create the required attribute). I'm against changing this. It's not because all correctly named features are considered required (on which I agree) that invalid feature names must lead to invalid widgets (on which I disagree). I think invalid feature names should be ignored. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [UMP] updated editor's draft of Uniform Messaging Policy on W3C site
On Tue, 05 Jan 2010 23:41:07 +0100, Tyler Close tyler.cl...@gmail.com wrote: I've uploaded an updated version of Uniform Messaging Policy, Level One to the W3C web site. See: http://dev.w3.org/2006/waf/UMP/ This version reflects feedback received to date and follows the document conventions of a FPWD. I look forward to any additional feedback. It's still not clear to me how the use cases in http://dev.w3.org/2006/waf/access-control/#use-cases are done using UMP. My apologies if I missed a reply to my email asking for that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [widgets] feature: inconsistent behavior ?
Marcos, Le 06/01/2010 10:52, Marcos Caceres a écrit : On Wednesday, January 6, 2010, Cyril Concolatocyril.concol...@enst.fr wrote: Le 05/01/2010 23:54, Marcos Caceres a écrit : On Wed, Dec 16, 2009 at 10:13 AM, Cyril Concolato cyril.concol...@enst.frwrote: Hi, The test df.wgt contains a feature without name. In this case, the feature element is ignored and the widget remains valid. The test d4.wgt contains an invalid feature name. In this case, the widget should be considered as invalid. I don't understand that. I understand the rationale that if a feature is required, the UA shall not process the widget. Whether it does or not understand the feature, it doesn't matter. Is it because you foresee evolution in the syntax of feature names, which wouldn't be IRI ? If not, I suggest to make this test pass and ignore the feature element. Sorry, but it was a resolution that all correctly named features are considered required (it's why we had to create the required attribute). I'm against changing this. It's not because all correctly named features are considered required (on which I agree) that invalid feature names must lead to invalid widgets (on which I disagree). I think invalid feature names should be ignored. But they (the invalid feature) are required by default (required value defaults to true), hence the widget would probably crash or be rendered useless at runtime regardless. Consider: feature name='foo:bar'/ which manifests itself as 'window.theMightyFoo' at runtime, iff the feature is available. The author, having implicitly said in the config doc feature foo:bar must be there for my widget to work will have to now write additional error handling code to check if the feature is available. This would be fine if the author said: feature name='foo:bar' required='false'/ in which case, the author has made an explicit statement that he or she has (hopefully) coded the widget on the premise that the feature may not be there at runtime. I think you misunderstood me. There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] PC simplifying some rules (editorial)
On 6 Jan 2010, at 08:56, Cyril Concolato wrote: [snip] 1 fails because we don't implement SNIFF. I don't know if we will. [snip] Actually you don't need to implement SNIFF to pass that particular test, as it only requires you do the extension-processing part of the algorithm. See, e.g.: https://svn.apache.org/repos/asf/incubator/wookie/trunk/src/org/apache/wookie/util/ContentTypeUtils.java As you can see we've put a TODO for SNIFF but the code as it stands passes the test fine. S smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] feature: inconsistent behavior ?
On 6 Jan 2010, at 10:08, Cyril Concolato wrote: I think you misunderstood me. There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. If a feature is required by the widget, and it isn't available for any reason (including an invalid IRI) then its reasonable for the UA to assume this Widget just won't work and reject it. It may simply be a typo, e.g.: feature name=http;//bondi.omtp.org/api/camera.capture required=true/ ^ typo! I don't think it would be useful for this to silently fail. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] PC simplifying some rules (editorial)
Le 06/01/2010 11:22, Scott Wilson a écrit : On 6 Jan 2010, at 08:56, Cyril Concolato wrote: [snip] 1 fails because we don't implement SNIFF. I don't know if we will. [snip] Actually you don't need to implement SNIFF to pass that particular test, as it only requires you do the extension-processing part of the algorithm. Thanks for the info, but I'm not sure I understand. If you take the algorithm: 1. nothing to do 2. content-type = empty 3. extension = empty 4. name = 'fail' 5. Not applicable (not starting with a full stop) 6. Not applicable (no full stop in the name) 7. Not applicable (no full stop in the name) 8. extension is empty so you go to 10. 10. Process the file according to SNIFF. Am I wrong? See, e.g.: https://svn.apache.org/repos/asf/incubator/wookie/trunk/src/org/apache/wookie/util/ContentTypeUtils.java As you can see we've put a TODO for SNIFF but the code as it stands passes the test fine. Your algorithm returns null even if the file is of a supported media type. In this case, it's fine, it gives the right result but if the 'fail' file did not contain garbage data but say real PNG data, your algorithm would give the wrong result. Anyway, thanks. I did not want to give the impression that I passed this test since SNIFF was not implemented but I will probably do something similar to you because I can actually give the right result for this test, which is what's needed for the report. However, the test suite should include one test really checking SNIFF support to see how many implementations do implement it. Cyril PS: In your code I noticed that line: if (filename.startsWith(,) filename.lastIndexOf(.)==0) return null; Are you sure the , shouldn't be a . ? -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/
Re: [widgets] PC simplifying some rules (editorial)
On 6 Jan 2010, at 12:09, Cyril Concolato wrote: Le 06/01/2010 11:22, Scott Wilson a écrit : On 6 Jan 2010, at 08:56, Cyril Concolato wrote: [snip] 1 fails because we don't implement SNIFF. I don't know if we will. [snip] Actually you don't need to implement SNIFF to pass that particular test, as it only requires you do the extension-processing part of the algorithm. Thanks for the info, but I'm not sure I understand. If you take the algorithm: 1. nothing to do 2. content-type = empty 3. extension = empty 4. name = 'fail' 5. Not applicable (not starting with a full stop) 6. Not applicable (no full stop in the name) 7. Not applicable (no full stop in the name) 8. extension is empty so you go to 10. 10. Process the file according to SNIFF. Am I wrong? No, you're correct - I'd misremembered the test details. See, e.g.: https://svn.apache.org/repos/asf/incubator/wookie/trunk/src/org/apache/wookie/util/ContentTypeUtils.java As you can see we've put a TODO for SNIFF but the code as it stands passes the test fine. Your algorithm returns null even if the file is of a supported media type. In this case, it's fine, it gives the right result but if the 'fail' file did not contain garbage data but say real PNG data, your algorithm would give the wrong result. Anyway, thanks. I did not want to give the impression that I passed this test since SNIFF was not implemented but I will probably do something similar to you because I can actually give the right result for this test, which is what's needed for the report. However, the test suite should include one test really checking SNIFF support to see how many implementations do implement it. I agree, we will need to have a test that exercises SNIFF properly, however the longer we put it off the better :-) Cyril PS: In your code I noticed that line: if (filename.startsWith(,) filename.lastIndexOf(.)==0) return null; Are you sure the , shouldn't be a . ? D'oh! Good catch - thanks! -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Mutimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.blog.telecom-paristech.fr/ smime.p7s Description: S/MIME cryptographic signature
Re: [widgets] feature: inconsistent behavior ?
On Jan 6, 2010, at 11:08 , Cyril Concolato wrote: There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. The ignore-unknowns strategy is largely built in order to support extensibility: because you ignore stuff you don't understand, it's possible for a v1 processor to process a v27 document (assuming it's designed to be compatible, which it should if it's using the same namespace). In the case of feature names however we already have all the extensibility that we ought to need: IRIs are completely open. Consequently I can't think of a situation in which an author would produce an invalid feature name on purpose, so this is an obvious error. -- Robin Berjon - http://berjon.com/
Re: [widgets] PC simplifying some rules (editorial)
On Jan 5, 2010, at 23:29 , Marcos Caceres wrote: Yeah, admittedly, it got a little messy wrt what defines a rule and what defines a step... that was me doing crazy literary experiments in the hope of making the spec easier to read and work with... I wanted to write rules like they were reusable functions, and the Steps as if they were independent parts of a program... not sure if I succeeded, FWIW I found it really useful. While implementing I basically made every rule into a method, then wrote the steps as one big processing chunk and it proved to be really simple. -- Robin Berjon - http://berjon.com/
Re: [UMP] updated editor's draft of Uniform Messaging Policy on W3C site
On Wed, Jan 6, 2010 at 1:58 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 05 Jan 2010 23:41:07 +0100, Tyler Close tyler.cl...@gmail.com wrote: I've uploaded an updated version of Uniform Messaging Policy, Level One to the W3C web site. See: http://dev.w3.org/2006/waf/UMP/ This version reflects feedback received to date and follows the document conventions of a FPWD. I look forward to any additional feedback. It's still not clear to me how the use cases in http://dev.w3.org/2006/waf/access-control/#use-cases are done using UMP. My apologies if I missed a reply to my email asking for that. Hi Anne, sorry for the delay in responding to your email. Which of these use cases are you having difficulty with? There have been several email threads about these use cases and corresponding solutions using UMP. Are you saying you didn't understand any of them, or one in particular, or is there one that was not covered? Thanks, --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [widgets] feature: inconsistent behavior ?
On Wed, Jan 6, 2010 at 11:30 AM, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 6 Jan 2010, at 10:08, Cyril Concolato wrote: I think you misunderstood me. There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. If a feature is required by the widget, and it isn't available for any reason (including an invalid IRI) then its reasonable for the UA to assume this Widget just won't work and reject it. It may simply be a typo, e.g.: feature name=http;//bondi.omtp.org/api/camera.capture required=true/ ^ typo! I don't think it would be useful for this to silently fail. FWIW, I agree with Scott. However, Cyril's point is valid in the the behavior is a bit inconstant with the spec... but, as Scott has shown through his example, it's with good reason. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] feature: inconsistent behavior ?
On Wed, Jan 6, 2010 at 3:13 PM, Robin Berjon ro...@berjon.com wrote: On Jan 6, 2010, at 11:08 , Cyril Concolato wrote: There is a difference between an 'unsupported'/'unavailable' feature as 'foo:bar' in your example and an 'invalid feature name' as in the test-suite example: widget named4/name feature name=invalid feature IRI required=true/ /widget I'm not asking that 'unsupported'/'unavailable' features are ignored as indeed this would contradict the default value of 'required'. I'm asking that 'invalid' feature are ignored (whether they are required or not). This would be consistent with the rest of the spec. The ignore-unknowns strategy is largely built in order to support extensibility: because you ignore stuff you don't understand, it's possible for a v1 processor to process a v27 document (assuming it's designed to be compatible, which it should if it's using the same namespace). In the case of feature names however we already have all the extensibility that we ought to need: IRIs are completely open. Consequently I can't think of a situation in which an author would produce an invalid feature name on purpose, so this is an obvious error. So you support leaving the spec as is, right? -- Marcos Caceres http://datadriven.com.au
Re: [widgets] white space handling
On Mon, Dec 21, 2009 at 9:43 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi Robin, Le 18/12/2009 18:01, Robin Berjon a écrit : On Dec 18, 2009, at 16:36 , Cyril Concolato wrote: Le 18/12/2009 15:58, Robin Berjon a écrit : P+C doesn't tie processors to a particular version of XML, and lists its white space characters accordingly (and defensively). If you're certain that you will only ever get content that comes from a conforming XML 1.0 implementation, then you probably don't need to check for this. I don't read it like that. PC explicitely references XML 1.0 and never mentions 1.1. So I thought the behavior was conformant to 1.0. It's fine if the spec also handles 1.1 but it should be mentioned. Also the rationale for the choices of space characters should also be indicated and the differences between XML 1.0 and XML 1.1 should be present. I beg to differ. I think that we should build specifications that can handle future changes to the stack I'm fine with that. without listing all the versions that are supported. It's not because you cite what you support that you're restricted to that. I think it helps understanding a spec. P+C is built for XML 1.0, and it's great that it has the resilience to handle changes to 1.1 without a hitch — but who knows what XML 4.2 might add? We can't guarantee that it'll work, but we can try (and if it does work, I don't think that we should list it either). I certainly don't think that it's the right place to document potential differences between versions of XML — as your XHTML example shows, that kind of information goes stale. If you're explicitely citing dated version of the spec, since they're cast in stone, I don't see how they can go stale. Furthermore, I didn't say that the differences between XML 1.0 and 1.1 are the rationale for this choice — I was merely indicating that using 1.1 you could get such characters and that P+C's robustness against that was a plus. I wasn't in Marcos's brain when that part was written but my specification exegesis antennae suspect that the listed class of characters corresponds to the Unicode white space character class (and therefore to what Unicode-aware processors would consider white space, notably \s in regular expressions). Well, you know my concern. I want to understand the spec in order to implement it properly. I'm not asking for any new normative statement, nor any change to the existing ones. I would be fine with informative notes explaining the intents of some choices. For example, as you know, I'm implementing an SVG UA and an PC UA, I want to know what's reusable, what's common without doing XML archaeology. Such notes would help me and I suspected it would help others. Nothing more. In the spec, I made that choice to be compatible with Unicode version 5. My intention was not to break XML parsers, but it sucks if that is what happened. I personally don't know how to proceed here. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] white space handling
On Mon, Dec 21, 2009 at 9:43 AM, Cyril Concolato cyril.concol...@enst.fr wrote: Hi Robin, Le 18/12/2009 18:01, Robin Berjon a écrit : On Dec 18, 2009, at 16:36 , Cyril Concolato wrote: Le 18/12/2009 15:58, Robin Berjon a écrit : P+C doesn't tie processors to a particular version of XML, and lists its white space characters accordingly (and defensively). If you're certain that you will only ever get content that comes from a conforming XML 1.0 implementation, then you probably don't need to check for this. I don't read it like that. PC explicitely references XML 1.0 and never mentions 1.1. So I thought the behavior was conformant to 1.0. It's fine if the spec also handles 1.1 but it should be mentioned. Also the rationale for the choices of space characters should also be indicated and the differences between XML 1.0 and XML 1.1 should be present. I beg to differ. I think that we should build specifications that can handle future changes to the stack I'm fine with that. without listing all the versions that are supported. It's not because you cite what you support that you're restricted to that. I think it helps understanding a spec. P+C is built for XML 1.0, and it's great that it has the resilience to handle changes to 1.1 without a hitch — but who knows what XML 4.2 might add? We can't guarantee that it'll work, but we can try (and if it does work, I don't think that we should list it either). I certainly don't think that it's the right place to document potential differences between versions of XML — as your XHTML example shows, that kind of information goes stale. If you're explicitely citing dated version of the spec, since they're cast in stone, I don't see how they can go stale. Furthermore, I didn't say that the differences between XML 1.0 and 1.1 are the rationale for this choice — I was merely indicating that using 1.1 you could get such characters and that P+C's robustness against that was a plus. I wasn't in Marcos's brain when that part was written but my specification exegesis antennae suspect that the listed class of characters corresponds to the Unicode white space character class (and therefore to what Unicode-aware processors would consider white space, notably \s in regular expressions). Well, you know my concern. I want to understand the spec in order to implement it properly. I'm not asking for any new normative statement, nor any change to the existing ones. I would be fine with informative notes explaining the intents of some choices. For example, as you know, I'm implementing an SVG UA and an PC UA, I want to know what's reusable, what's common without doing XML archaeology. Such notes would help me and I suspected it would help others. Nothing more. I made that choice to be compatible with Unicode version 5. My intention was not to break XML parsers, but it sucks if that is what happened. I personally don't knmow -- Marcos Caceres http://datadriven.com.au
