Re: [widgets] feature: inconsistent behavior ?
On Jan 6, 2010, at 20:47 , Marcos Caceres wrote: 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? Yes indeed. -- Robin Berjon - http://berjon.com/
Re: [widgets] white space handling
On Jan 6, 2010, at 21:58 , Marcos Caceres wrote: 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. You broke nothing, there is no problem. What these P+C rules operate on is content, which is Unicode, and therefore using Unicode's WS is perfectly sensible. I think Cyril was mostly asking about having a note explaining where this list comes from (which would have helped him find out why it's different from the list of WS chars used elsewhere). -- Robin Berjon - http://berjon.com/
Publishing Selectors API Level 2 as an FPWD?
Hi, Now that Selectors API Level 1 is published and basically all but finalised (just waiting for some implementations to be officially released before taking it to REC), can we publish Selectors API Level 2 as an FPWD? It would be useful to have it more widely reviewed, especially since Mozilla and WebKit have begun their implementation of matchesSelector, which is defined in it. The editor's draft is here. http://dev.w3.org/2006/webapi/selectors-api2/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
[widgets] Draft Minutes for 7 January 2010 Voice Conference
The draft minutes from the January 7 Widgets voice conference are available at the following and copied below: http://www.w3.org/2010/01/07-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 14 January 2010 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Web Applications Working Group Teleconference 07 Jan 2010 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0053.html See also: [3]IRC log [3] http://www.w3.org/2010/01/07-wam-irc Attendees Present David, Art, Steven, Marcos, Robin, Marcin_Hanclik, Marcin, Josh Regrets Frederick Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]Letter from ISO JTC1/SC 34/WG4 4. [8]Status of URI Scheme spec 5. [9]Status of View Modes Media Features (VM-MF) spec: 6. [10]Status of Updates spec 7. [11]AOB * [12]Summary of Action Items _ trackbot Date: 07 January 2010 Steven oops scribe Scribe: Art Steven How many people are joining? scribe ScribeNick: ArtB scribe Meeting: Widgets Voice Conference Date: 7 January 2010 Review and tweak agenda AB: the draft agenda was sent out yesterday ( [13]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/00 53.html ). Any change requests? [13] http://lists.w3.org/Archives/Public/public-webapps/ 2010JanMar/0053.html [ no ] Announcements AB: WARP LC comment period ends Jan 13. Does anyone have any short announcements? [ no ] Letter from ISO JTC1/SC 34/WG4 AB: On 29 December, Mohamed ZERGAOUI sent WebApps an letter ( [14]http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/15 00.html ) on behalf of ISO SC34/WG4. The letter notes some similarities between our widget packaging spec and their Open Packaging Conventions spec. ... I have not read the OPC spec; anyone read it? [14] http://lists.w3.org/Archives/Public/public-webapps/ 2009OctDec/1500.html MC: I read it AB: anything you want to share about it? MC: during our req gathering phase, we discussed similarities ... I have refs to the original emails ... this was mentioned by IBM (JonF) ... it was at least 2 years ago ... a conclusion was that ISO should start a ISO ZIP WG ... but don't know if that started or not ... I think ISO should create an ISO ZIP spec ... it would be good to get a real ZIP standard ... and not just some PKWare spec AB: I recall those conversations with JonF on this subject timeless_mbp Zakim: +??p12 is me scribe ACTION: barstow respond to Mohamed's 29-Dec-2009 email from ISO SC34/WG4 [recorded in [15]http://www.w3.org/2010/01/07-wam-minutes.html#action01] trackbot Created ACTION-474 - Respond to Mohamed's 29-Dec-2009 email from ISO SC34/WG4 [on Arthur Barstow - due 2010-01-14]. AB: after I respond, Marcos, perhaps you can respond too MC: OK AB: anything else on this topic for today? [ no ] Status of URI Scheme spec SP: should this ISO be coordinated via HCG? ... external coord typically goes thru HCG AB: good question ... I can forward it to HCG and seek comments SP: yes, a heads-up to them would be good scribe ACTION: barstow forward ISO packaging email to HCG [recorded in [16]http://www.w3.org/2010/01/07-wam-minutes.html#action02] trackbot Created ACTION-475 - Forward ISO packaging email to HCG [on Arthur Barstow - due 2010-01-14]. AB: Robin, what is the status of the URI Scheme spec ( [17]http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ )? [17] http://dev.w3.org/cvsweb/2006/waf/widgets-uri/ RB: Larry replied on the TAG list ... also got some feedback from Jonathan Rees ... we need to continue discussions AB: so related discussions are happening on www-tag? RB: yes AB: we all have an action to contribute to the related discussion on www-tag ... I haven't been following that list ... anything else on this spec for today? RB: no; Larry's comments need to be discussed Status of View Modes Media Features (VM-MF) spec: AB: would one of the Editors of the VMMF spec please give a short status of the spec ( [18]http://dev.w3.org/2006/waf/widgets-vmmf/ ). [18] http://dev.w3.org/2006/waf/widgets-vmmf/ MH: last month I commented on VF's related input ... I am in the process of reflecting those comments in the spec ... but only a local copy now ... I will have something to review in a week ... the VF proposal included some interfaces
Re: MPEG-U
Hi Robin, Le 06/01/2010 17:43, Robin Berjon a écrit : Hi Cyril, sorry to put you on the spot, but I don't recall this being discussed by WebApps I know that a liaison was sent from MPEG to the W3C early may 2009 and that the WG was informed. and you're listed as one of the authors: http://www.chiariglione.org/mpeg/technologies/mpeg-u/mpu-widgets/index.htm Can you give the WG some general ideas about what's happening around MPEG-U? Actually, I had made a web page that describes it and that I wanted to send earlier [1]. You will find there some background information and the current spec in PDF and soon some examples and code. If you have questions about the GPAC implementation of MPEG-U, you can ask me but if you have questions about the MPEG process, you can post them on the general MPEG Systems mailing list[2]. Cyril [1] http://concolato.blog.telecom-paristech.fr/widgets/mpeg-u/ [2] http://lists.uni-klu.ac.at/mailman/listinfo/gen-sys One reason I'm asking is because some of the work items in that document are interesting in a generic manner, and therefore are things that could make their way into WebApp's charter when it comes up for rechartering (which is soon). I don't think that all that's listed there would be of interest to WebApps (e.g. I'd be surprised if the WG cared about integration with BIFS or ISOFF packaging, assuming members even have heard of them), but some topics (inter-widget communication, context management, aggregation) certainly are. Given MPEG's patent policy and inexperience with web technology one can take a fairly good bet that if MPEG-U defines solutions in this space WebApps won't adopt them, thereby leading to fragmentation: something that the document above states it wishes to avoid. Hence my interrogation; can you enlighten us? 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/
Re: [widgets] feature: inconsistent behavior ?
On Thu, Jan 7, 2010 at 4:10 PM, Cyril Concolato cyril.concol...@enst.fr wrote: Le 06/01/2010 20:46, Marcos Caceres a écrit : 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. Now that I understand the rationale, I'm fine to leave it as is. It just means that the spec will not be extensible to features not named with IRI. I don't know if in Robin's v27 of the spec, there won't be a different way to name features. Don't worry about Robin, I'll personally make sure he stays well away from any future versions of the spec :) But seriously, I think URIs have proven themselves to be pretty robust and usable; they also provide (fairly) well-understood structured semantics, which some implementers may find useful - hence the reason we chose them for the name instead using a opaque string or something else. Also, we have not tied naming to any particular URI scheme, which also gives a great deal of flexibility. -- Marcos Caceres http://datadriven.com.au
[widgets] DigSig - proposed change to XML Signature Properties
The XML Security WG is considering changing the syntax of the Profile
and Role elements of the XML Signature Properties spec.
It appears to me the proposed change would affect at least sections 5.
{1,2,3} and the example.
If you have any comments on the proposed changes, please send them to
both public-webapps@w3.org and public-xml...@w3.org.
Frederick, Scott - would you please explain the rationale for the
proposed change?
-Art Barstow
Begin forwarded message:
From: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com
Date: January 7, 2010 1:31:20 PM EST
To: ext Scott Cantor canto...@osu.edu
Cc: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com, XMLSec WG Public List public-
xml...@w3.org, Barstow Art (Nokia-CIC/Boston)
art.bars...@nokia.com
Subject: Re: ISSUE-163, standalone XSD and RNG schema needed for
Signature Properties
Thanks very much Scott.
I'll check with Art Barstow, Chair of WebApps regarding the suggestion
to change the Profile and Role elements to see if that would have a
negative impact on them.
What do others think, any issue with making that change if acceptable
to the Webapps WG? Any objection?
specifically, I think the suggestion is to change
element name=Profile type=dsp:ProfileType/
complexType name=ProfileType
attribute name=URI type=anyURI/
/complexType
to
element name=Profile type=anyURI/
and likewise for Role.
Are there any other issues or concerns with this updated schema that
Scott sent? I'd like to update the Signature Properties schema
snippets to match, link in this schema, and get help on creating an
RNG schema (anyone here feel that they can handle it for this
relatively simple schema?)
I'd also like to incorporate an example as Scott suggests, preferably
one from WebApps.
regards, Frederick
Frederick Hirsch
Nokia
On Jan 7, 2010, at 12:18 PM, ext Scott Cantor wrote:
I checked in a draft xsd schema file after extracting the schema
from
the examples and starting to try to fix some errors, in case that
helps an easier start:
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/xmldsig-
properties-
schema.xsd
A valid version is attached, with the following changes:
- fixing some errors and missing prefixes
- removing extra type definitions when the element is just a
string or
dateTime
In addition, I would suggest changing the two properties that are
empty
elements with the URI attributes into elements with a type of anyURI
and
just putting the value into the element.
Note that I'm also just correcting the schema as given, and since
there are
no examples in the document, I can't tell you for sure whether the
XML you
*want* is represented.
-- Scott
xmldsig-properties-schema.xsd
Re: [widgets] DigSig - proposed change to XML Signature Properties
Given the CR stage [1] of Widgets Signature, it probably makes sense
to not make this schema change, since it would break implementations,
even though changes are still allowed at this stage. As Scott notes,
it is more of a style issue - however I thought it worth mentioning
given that Signature Properties is about to enter Last Call.
regards, Frederick
Frederick Hirsch
Nokia
[1] http://www.w3.org/2005/10/Process-20051014/tr.html#cfi
On Jan 7, 2010, at 2:17 PM, Barstow Art (Nokia-CIC/Boston) wrote:
The XML Security WG is considering changing the syntax of the Profile
and Role elements of the XML Signature Properties spec.
It appears to me the proposed change would affect at least sections 5.
{1,2,3} and the example.
If you have any comments on the proposed changes, please send them to
both public-webapps@w3.org and public-xml...@w3.org.
Frederick, Scott - would you please explain the rationale for the
proposed change?
-Art Barstow
Begin forwarded message:
From: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com
Date: January 7, 2010 1:31:20 PM EST
To: ext Scott Cantor canto...@osu.edu
Cc: Hirsch Frederick (Nokia-CIC/Boston)
frederick.hir...@nokia.com, XMLSec WG Public List public-
xml...@w3.org, Barstow Art (Nokia-CIC/Boston)
art.bars...@nokia.com
Subject: Re: ISSUE-163, standalone XSD and RNG schema needed for
Signature Properties
Thanks very much Scott.
I'll check with Art Barstow, Chair of WebApps regarding the
suggestion
to change the Profile and Role elements to see if that would have a
negative impact on them.
What do others think, any issue with making that change if acceptable
to the Webapps WG? Any objection?
specifically, I think the suggestion is to change
element name=Profile type=dsp:ProfileType/
complexType name=ProfileType
attribute name=URI type=anyURI/
/complexType
to
element name=Profile type=anyURI/
and likewise for Role.
Are there any other issues or concerns with this updated schema that
Scott sent? I'd like to update the Signature Properties schema
snippets to match, link in this schema, and get help on creating an
RNG schema (anyone here feel that they can handle it for this
relatively simple schema?)
I'd also like to incorporate an example as Scott suggests, preferably
one from WebApps.
regards, Frederick
Frederick Hirsch
Nokia
On Jan 7, 2010, at 12:18 PM, ext Scott Cantor wrote:
I checked in a draft xsd schema file after extracting the schema
from
the examples and starting to try to fix some errors, in case that
helps an easier start:
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-properties/xmldsig-
properties-
schema.xsd
A valid version is attached, with the following changes:
- fixing some errors and missing prefixes
- removing extra type definitions when the element is just a
string or
dateTime
In addition, I would suggest changing the two properties that are
empty
elements with the URI attributes into elements with a type of anyURI
and
just putting the value into the element.
Note that I'm also just correcting the schema as given, and since
there are
no examples in the document, I can't tell you for sure whether the
XML you
*want* is represented.
-- Scott
xmldsig-properties-schema.xsd
RE: [widgets] DigSig - proposed change to XML Signature Properties
Arthur Barstow wrote on 2010-01-07: Frederick, Scott - would you please explain the rationale for the proposed change? I was asked to produce an XSD for the Signature Properties document, and I saw that it was using an overly complex syntax to express something that's just a URI. Using complex XML types tends to bother some people's software much more than using simple text node element content does. It's just a personal observation based on experience. If you have this in running code and don't want to change it, that's fine. -- Scott
[UMP] A declarative version of Uniform Messaging Policy
I've updated the UMP spec to use a declarative style and moved the algorithmic specification to a non-normative appendix. Hopefully this organization will appeal to fans of either style. See: http://dev.w3.org/2006/waf/UMP/ I'm hoping to move UMP forward to FPWD as soon as possible. Please let me know if there is anything I need to do to expedite this process. Thanks, --Tyler On Tue, Jan 5, 2010 at 2:41 PM, 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. Thanks, --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
