See also: IRC log
AB: Arve had a last minute
cancelation and will not attend
... registered but not here yet: Paddy, Richard Tibbett,
Jonathon, Nick and Ivan
AB: all of the minutes will be
Public
... any questions about that?
[ None ]
AB: Agenda:
http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda_Items
... we will start with P+C this morning
... talk about high priority issues
... from 13:00-15:00 today we will talk about Security Model
vis-a-vis <access> and the WARP document
AB: spec: http://dev.w3.org/2006/waf/widgets/
... other than feature and L10N are there other hot topics?
MC: no not really
AB: Henri's
http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0699.html
... comment about clarifying purpose of feature
... I think the way we have documented feature in P+C is
OK
... but there are questions about what a UA will do with the
data
... what is our plan to specify the behavior?
<scribe> Scribe: Art, Mike
<MikeSmith> Scribenick: MikeSmith
ArtB: what work remains to be done for <feature>?
Marcos: I don't think anything more needs to be done.. it's specified.
ArtB: Anybody disagree with that?
Marcos: Biggest impact is on
BONDI, so it matters most if it is OK as-is for them.
... I think it meets the BONDI use cases.
Robin: If OMTP is OK with it, I'm
OK with it.
... I'm happier with use cases that don't require it, because
that's more Web-like.
David: In the absence of a more
proper security model, we still support this.
... We are happy for [the editors] to take the lead on
this.
Marcin: We just want it to be stable.
ArtB: Is OMTP going to extend it after?
Bryan: We may add some semantics, but we are not planning to add additional attributes.
David: If we have a policy mechanism -- some way of regulating access for the user -- then this element is actually redundant.
Marcos: So it really is more of a stop-gap for now
ArtB: Anybody else have anything to add on this topic?
PROPOSED RESOLUTION: The group agrees that the <feature> element as defined in the LC WD is complete.
ArtB: Any objections?
[none]
RESOLUTION: The group agrees that the <feature> element as defined in the LC WD is complete.
Marcos: [discussing issue of case sensitivity in localization system]
[discussion about mailing-list discussions from last couple days]
Marcin: [talking specifically about recent BONDI decisions around requestFeature() and widgets vs. Web pages]
Marcos: as far as requestFeature(), as this point, it does not exist in the Widgets specs.
David: Yeah, we are still just discussing it within OMTP.
Marcin: [explaining background on submission of BONDI specs for review within W3C]
Bryan: One question is: Do we
have the ability to author [a document] as both a Web page and
a Widget.
... Another question is around dynamically loading.
Marcos: I think the DAP WG will be the one that needs to answer that.
timeless_mbp: because of localization and path constraints, currently you won't be able to [drop a widget into a page and have it work]
Marcin: In theory, for this case, the widget UA should be behaving conceptually in the same way as an HTTP server.
ArtB: What I see is that David announced "we are now done, please review"
David: So if it's the view of the WebApps WG that getFeature() is more correctly specified within the DAP WG, then we would follow your lead on that.
Marcos: The problem is that it currently seems to make assumptions about a particular architecture.
Robin: Yes, the feedback you are likely to get from browser vendors is that as currently specified, it does not match with browser architecture, and there are other ways to solve the problem.
Marcin: The whole BONDI
initiative came about because of need for a "fast standard"..
but BONDI operates under many of the same principles as the
W3C.
... The expectation is that everything that has been produced
by BONDI will be reviewed within W3C... but none of what BONDI
has produced thus far is considered a "must".
David: so to step back, we don't have DAP yet, so we need a stop-gap in the meantime to address the issue
<scribe> Scribenick: Bryan
<ArtB> Jere's comments: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0723.html
<ArtB> P+C ED: http://dev.w3.org/2006/waf/widgets/
Jere: comments were mostly editorial
<ArtB> Macros' response to Jere: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0824.html
Marcos: the main issue was case
sensitivity in localisation
... effectively what we have for localisation is a language
list and a list of folders. the algorithm is to do a string
match, case sensitively.
... the solution is to match everything in the local part of a
path case-insensitively
Josh: forcing failure for
anything other than lowercase is another option
... it is easy to write an algorithm than discards anything
that does not match with lower case
Marcos: we need to ensure we don't violate ISO specs re case requirements
Robin: we don't need to follow the ISO specs
Josh: the widgets spec is not defining a language code thus we don't have to follow rules for languages
<Marcos> RESOLUTION: in the spec, we will mandate that language tags for locale folders be in lowercase form (relevant to authors). Only locale folders in lowercase form will be matched by the widget user agent.
Jere: is it possible to have upper-case folders present anyway, and the sensisble thing is to fold it to lower case and continue
Robin: the sensible thing to do is to discard folders that are non-conformant
Jere: compromise, allow any case as long as it's unique and then treat it as lower case
Robin: in a case insensistive file system, how to handle if the language tag folders are not unique - the easiest is just to kill them
Bryan: what is the downside of ensuring uniqueness and case folding?
Josh: it can cause confusion as the author was expecting one behavior and gets another
<timeless_mbp> DRAFT RESOLUTION: any folder as a direct child of the locales folder whose name is not entirely in lowercase will not be reachable by any means.
David: is there any existing requirement mandating lowercase in the specs?
Josh: there is precedent in other specs to require case sensitive matching
No objections.
RESOLUTION: any folder as a direct child of the locales folder whose name is not entirely in lowercase will not be reachable by any means.
Art: are there still some comments on localisation outstanding?
Jere: some editorial comments, the email exchange is ongoing
Marcos: it was proposed to
reshuffle the content which is now done, e.g. the localisation
is now in one area. Need to do a read-thru to ensure good
flow
... there's nothing else that is editorial - the question on
xml:lang needs to be resolved
Josh: in 5.3 the locale/folder needs to not reference the folder name - it needs to be called "locale folder" or something that makes it clear what we are referring to
<timeless_mbp> not locale folder since that's taken
<timeless_mbp> but locale-folder-name which might reference BCP47 with a prose restriction to lowercase, or a copy of BCP47 with the BNF restricted to lowercase
Marcos: to fix this, we need to change elements of the ABNF if we were to take the language tag from bcp47
Robin: it is better to restrict it in prose rather than ABNF
<timeless_mbp> ok :)
Jere: the issue raised re xml:lang values being unique, does this come from I18N best practices?
Michael: from HTML5, for authoring we have encouraged people to move away from xml:lang
Robin: that's because HTML4 had a
lang tag and there is thus duplication. in our case we are
starting from scratch
... for widgets, we define the processing model and it will
clarify how to handle the set of xml:lang entries
Marcos: the entries are specified to be in document order
Marcin: does this work related to ITS?
Marcos: it relates since the ITS affects to to handle character sequences
Jere: the issue is resolved since the description will define the handling
Marcos: in the 1st example of
step 5, we need to make the language sequence consistent, and
to ensure what is being ilustrated is correct
... the use case is the user has entered the language
preferences, and the widget user agent ensures the list of
languages is per the spec, and to avoid confusion we need to be
clear on how it does that
Benoit: is there a point inthe processing model, how specific the selected language needs to be
Marcos: there are those who want a specific dialect over the generic or another dialect
Josh: there are those that would prefer english for example to an unknown dialect of their language
Marcos: the question is how to eliminate repetitions/ambiguity in the selected list
Josh: the processing should enable e.g. avoidance of random untagged english if another language is preferable
Art: are there any objections to the processing model presented on the screen?
<Marcos> Draft Resolution: treat language tags in the order they appear in the UA Locale list, instead of treating them as recommended by BCP47.
<Marcos> "en-us,en-au,fr,en"
<Marcos> Would become:
<Marcos> "en-us,en-au,fr,en"
<Marcos> "en-us,en-au,fr"
<Marcos> Would become:
<Marcos> "en-us,en-au,en,fr"
Josh: the example does not yet quite meet the draft resolution
Art: it's a question for Josh and Marcos to figure out how to word in the spec
Resolution: treat language tags in the order they appear in the UA Locale list, instead of treating them as recommended by BCP47.
Jere: an outstanding issue is the runtime resolution of the resources, we can discuss that later
<ArtB> Scribe+ DanA
<darobin> do you see me?
<tlr> darobin, if you could dial into the bridge?
<DKA> Scribe: Dan
<DKA> ScribeNick: DKA
[back from lunch]
Art: I'm projecting the June 5
version of the WARP document.
... We want to use this time to go through this document and
solicit comments. One question I'd like to pose is - is there
consensus to publish the document as FPWD?
<ArtB> http://dev.w3.org/2006/waf/widgets-access/
Art: over to Robin for a quick walk-through
Robin: To give some background -
this spec defines the access element which was previously in
PnC and got dropped out to a separate spec rather than delay
PnC.
... It follows typical structure.
... It has a simple model whereby the access grants access
within the widget execution scope to certain network resources
but anything that is outside the widget executtion scope
... does not have the same levels of access.
... The advantage: it maintains protection to sensitive APIs
because you can't communicate across iframe boundaries.
etc...
Bryan: clarify?
Robin: if you have a widget with access to the address book (e.g.) and in a separate context you have an access element that grants it to load something from a foreign host then this context will not have access to the address book.
<Zakim> Thomas, you wanted to note that it *can* communicate, but the widget is able to control that access
Thomas: to clarify - a very
limited amount of communication is possible using APIs like
post message... you do have cross-origin communication within a
browser. But this is tightly controlled by the widget. The
important point is that the widget cannot script the iframe and
the iframe cannot script the widget.
... This gives us a very well-defined interface and puts
relatively strict limits - doesn't give access from the web to
"risky" APIs yet.
Robin: there's no information leakage unless you've trusted an evil widget.
Josh: With an iframe, to a normal
user, you can load a javascript URL that executes arbitrary
code in the context of that web page.... Assuming the widget
will not be allowed to do that.
... That code executes in the context of the iframe. It doesn't
have access to the widget but it has total access to the
iframe.
Robin: Yes.
Josh: So it's not a very tall wall in that direction.
<Zakim> timeless_mbp, you wanted to verify that the widget can't load javascript:scriptWidget() in the iframe
Robin: The rest of the spec is
the syntax and the processing model.
... There have been two messages so far with editorial comments
which I'll apply before we publish.
[discussion of the comments from Thomas from today]
<ArtB> TLR's comments today: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0859.html
Thomas: Point 3 in my notes - I
continue to not be convinced that it's a good idea to build a
new model within the widget that contains inline content.
... other points raised are editorial in nature.
... [discusses his additional comments]
... To give an example, the document talks about parsing in
document order but this doesn't have anything to do with this
specification.
... [suggests compressing the parsing instructions]
Robin: WRT point 2. I was thinking that it shouldn't say anything about HTML5 security policy but should just say that it uses the security policy "of the host language being used" which removes the dependency on HTML5.
Josh: there are 2 parts that reference HTML5.
Art: Any objections to that proposal?
Josh: The other HTML5 reference needs to point to some other thing.
Bryan: [clarify web application scope?]
<ArtB> [ Discuss "The widget execution scope is the scope (or set of scopes, seen as a single one for simplicity's sake) being the execution context for code running from documents that are part of the widget package. Note that a script loaded from an external URI into a document that is part of the widget is running in the widget execution scope. " ]
Bryan: If I load a script off of the Web and I run that within a container that is part of the html page that the widget as defined, is that web scope or widget scope?
Robin: If the access has been granted by the access element then it is running in the widget context.
Bryan: if I load further scripts then those have the same permissions?
Robin: Yes.
Bryan: Where do we transition to the Web scope?
Robin: If you have another document - like an iframe - which has an origin that is not inside the widget.
<timeless_mbp> for my reference, CORS is http://www.w3.org/TR/cors/
Robin: The case of bringing in
script from the web relys on the access element having granted
that access [in the widget context] so subject to the access
policy.
... A widget can contain multiple documents... All of those
documents run within the widget scope. If one of those runs a
script from a URI on the web then that script is running in the
widget context.
... We don't want to constrain the security models for others
within this spec.
... We don't want to break the Web.
Bryan: Suggests inserting a [zzzt zzzt]
<tlr> [awfully noisy call right now]
<darobin> http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0732.html
Bryan: Suggests inserting a concrete example in the document to clarify.
Frederic: I support having more details in the examples - e.g. the airline flight tracker. If you have a feature that allows access to the camera ...
<timeless_mbp> Zakim: mute [london]
Frederic: it talks about feature-enabled APIs in section 2. I assume feature enabled then that feature applies to anything [in that context].
Thomas: Any script that can control the widget execution context would have access to that feature.
Robin: I will put a specific example in to clarify.
Frederic: This is truly for network access and not for anything else (e.g. a URI to a feature).
Bryan: A local host URI such as a smartcard web server would be covered.
[yes]
Robin: Your definition of a network resource is anything with a URI that is referenced by DNS or IP.
[agreement]
<Zakim> timeless_mbp, you wanted to ask if <access uri="http://redirect.example.org"> and a widget has <iframe src="http://redirect.example.org/?http://somethingelse.com"> would be
Robin: If access says it's OK to access foo.com and you load foo.com and it redirects to bar.com.
Josh: [advertisement for CORS
Thomas: Don't have an easy answer
to the redirect question. Not clear that CORS is the answer.
The fundamental distinction we have is ...
... just mixing redirects and origin determination could be a
huge security hole.
Frederic: We have the asterix which allows access to all assets - could this become a problem?
Robin: this was debated before but not everyone was happy with the solutiuon. But if you want to access something like google maps you get a zillion subdomains...
Steve: There's no way to state that intent more explicitly?
Robin: if you enable foo.com and its subdomains then it could allow access to an IP address in your internal network.
[consensus we need to fix the web or something]
Robin: a user agent would assign an opaque, unique, global identifier to each instance.
Thomas: I suggest we leave this open because there is a proposal to assign the same identifier to different widgets if they have been signed with the same cert.
Robin: We remain silent.
Josh: What about multiple instances?
Robin: Currently undefined.
Thomas: We don't know right now -
probably something we should leave undefined at this
time.
... When it comes to local storage they would have to take care
of not stepping on eachother's toes. That's the one [problem
area I see with multiple instances]
Art: where are we wrt FPWD?
<lewontin> Possible that device access security model might further restrict access beyond same-origin.
<fjh2> I was the speaker asking about making intent more explicit...
<lewontin> This shouldn't affect anything in this spec explicitly.
Art: What kind of time-frame are you thinking?
Robin: I can do it this week.
Art: I'd like to give Robin the freedom to make those changes.
PROPOSED RESOLUTION: The WARP document modulo the changes Robin's agreed to make is ready for FPWD.
[no objections]
RESOLUTION: The WARP document modulo the changes Robin's agreed to make is ready for FPWD.
Robin: Short name?
Art: My recommendation is widget-access
[discussion on what to cover next]
<ArtB> Spec: http://dev.w3.org/cvsweb/2006/waf/widgets-uri/Overview.html
<darobin> http://dev.w3.org/2006/waf/widgets-uri/
Art: Over to Robin.
<Marcos> http://dev.w3.org/2006/waf/widgets-uri/
Robin: This isn't up to date with
the latest edits.
... I want to propose that the authority is a string that must
be ignored in this version. Paves the path forward for use of
signatures in future versions.
<Marcos> Scribe+ Marcos
<Marcos> ScribeNick: Marcos
RB: with the issues listed at the begining, plus a few other things, we have enough to run with for version 1
<tlr> works for me
<tlr> certainly ready for FPWD
JS: what does it mean to ignore the authority?
RB: [gives background on
whiteboard]
... we started that the Origin was synthetic opaque with a
UUID, then ppl complained about the UUID so we got rid of it.
So the authority part could be used for other things, like
crypto.
JS: the DOM should not reflect that authority?
RB: in future versions, we might make use of the authority part
TR: so my understanding is that,
when the URI gets dereferenced, the authority part gets
ignored...
... the authority does not carry any semantics right
now...
... the idea is just to keep it open for now, so we can do more
with it later
RB: Agreed
SL: might need to clarify that in section 4 of the spec
TR: need clarifications or it's going to be hard to parse
<tlr> 3986
RB: it still conforms to the URI specification, and the UUID would still be dropped
<tlr> (thinking about this, I was wrong; ignore)
<tlr> (about the character repertoire, that is)
<lewontin> Maybe we want to drop the word "unique" in section 4 since we left open the possibility that multiple instances or multiple widgets might share the same URI
<tlr> +1 to dropping "unique"
JS: I need to read the spec, will
try to do that now
... have editorial comments
AB: if we look at the issues at the top of the doc. It seems we have closed a few of those issues
RB: a lot of those are
editorial
... so unicode, UUID are dropped. Can reference a bunch of
things from P&C. And the thing about dig sig, not sure what
I meant.
JS and RB discuss some minor issues
AB: It's highly likely we are going to get some feedback once this goes out. So, I'm inclined to push of a FPWD ASAP.
RB: I can have it ready this week
AB: the question is the, should we agree on a FPWD today?
RB: I think so
MC: I agree
AB: Robin will make the changes, so I propose to the group that we get a resolution to publish
PROPOSED RESOLUTION: The group agrees to publish a FPWD once changes agreed on during this discussion have been spec'd.
RB and BS discuss synthetic origins
<ArtB> BS: I would like to see a definition of synthetic added
<ArtB> RB: yes, I will add a definition
RB: a lot of people were uncomfortable with widget://
<tlr> tlr; think it's a bad idea to have a URI scheme which you can't ever write out in absolute
<tlr> tlr: think it's fine to have authoring guideline that says "relative uri references preferred"
<tlr> tlr: bu also think it's a bad idea to forbid them in the implementation
BS: if I want to call a local resource, can I pass it a parameter?
RB: it should work, the
javascript could access the relevant document property and
access that information
... you would not be able to post to a widget URI
JS: when I talked to TR, we agreed that POST would not work for 1.0, but may be something that gets added later
BS: how does this work with HTTP?
RB: there is no relationship to HTTP, it's just a URI
TR: the only thing we define for the URI scheme is how to retrieve files form a packaged, but nothing else. WRT queries, they are ignored, but is reflected in the DOM... but we don't say that right now, but it should say it in the spec
RB: fragments also
... ppl will be surprised if they are not there
TR: query is part of the resource
identification
... fragment happens after the uri is dereferenced
RESOLUTIONS: The group agrees to publish a FPWD once changes agreed on during this discussion have been spec'd.
<ArtB> Larry: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0642.html
AB: before we close this topic, I did want to follow up on this topic. Larry sent an email about thismessage
<ArtB> AB: the wiki http://www.w3.org/2008/webapps/wiki/WidgetURIScheme
AB: at some point we were keeping
track of all the candidates for URI schemes
... in the wiki
RB: on first reading, it seemed very MIME constrained
JS: yes, I found the same thing.
JS reads the abstract
<timeless_mbp> http://www.rfc-editor.org/rfc/rfc2557.txt
<timeless_mbp> last paragraph, first sentence
<timeless_mbp> This document a) defines the use of a MIME multipart/related
<timeless_mbp> structure
<timeless_mbp> -- if the abstract is accurate, then the RFC isn't portable for us
RB: I think we need to deconstruct it and see what is good/bad in there
<timeless_mbp> -- if the abstract is not accurate, then the RFC isn't worth reading
<timeless_mbp> oh, *of first page
<scribe> ACTION: Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action01]
<trackbot> Sorry, couldn't find user - Send
<scribe> ACTION: Robin to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action02]
<trackbot> Created ACTION-353 - Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [on Robin Berjon - due 2009-06-16].
RB: from what I read it was _very_ MiME related
BS: what is the context of this discussion?
JS: the TAG is against creating new URI schemes unless one is REALLY needed
AB: the history here is that we decided we needed a new URI scheme for widgets, but we need to explore the whole landscape to make sure nothing fits.
RB: I'm happy to discuss this
with the TAG
... I love the TAG, I'm hoping I will be appointed to it.
<darobin> MC: I want to chair the AB
<Bryan> hello
<darobin> Scribe+ Robin
<ArtB> ScribeNick: darobin
AB: Jere, did we finish your comments?
JK: I think so yes, waiting on an email from MC for formal acknowledgement
MC: will do that
JK: do we need that for the DoC? Do I need to say I'm happy?
MC: yes
JK: not trying to push MC
MC: need to make sure I've addressed everything
AB: from a process & scheduling perspective LC ends on 19/06, so no specific rush
JK: happy to co-ordinate offline
AB: that's done
... anything heard from XML Core?
MC: no
<scribe> ACTION: Art to ping XML Core and the XML CG about reviewing our PC LC [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action03]
AB: MWBP was also reviewing
<scribe> ACTION: Art to follow up with MWBP chairs for LC comments [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action04]
AB: Marcin, you've sent several
comments
... do you want to discuss them in the group
MH: I think we're handling it on
the mailing list
... I'm not sure who else would speak up about versioning and
interoperability
AB: I wanted to talk about
versioning
... what is the consensus about versioning for PC — emails
trail off but that doesn't mean we have consensus and no
issues
MC: I think we're fine
... we have made it as future-compatible as possible based on
past experience, on other groups' languages, on their
recommendations
... we think our processing model is solid enough to handle the
future
RB: I agree
MH: I think on the mailing list
we've agreed that versioning is built on the NS, if there's
incompatibility we can change it
... spec grows monotonically
... ensure back-compat of new releases
... two aspects: 1) the versioning of the format, 2) versioning
of the APIs
... e.g. Geolocation
MC: the P+C doesn't concern
itself with the APIs
... but in P+C we take the same architectural approach
... future-compatibility without explicity versioning
... because you end up with a situation whereby you need to
support previous versions, it's heavy
... lots of legacy crap, like WAP, because there's content out
there that uses it
... we want to avoid that
MH: this changes my
understanding
... you want to drop support for some APIs
MC: no, we just want to support one evolving API built to be back-compatilble
MH: you assume there will be no deprecation
MC: yes
RB: and if there are breaking changes we change the name — just like for namespaces
Magnus: at some point you make changes, how do you determine whether that something has changed without versioning?
MC: that approach doesn't work,
it doesn't live up to the lifespan that web content has
... "at least 100 years" is a design principle
... running the same Tetris a century from now
... archive.org should still run
... it's about creating a communication medium that will stay
there for a very very long time
... instead of dying after a few years
... pages from 1991 still work
MH: you don't know it's from 1991
MC: and you don't care — which is the point
BS: that works as we have a slow transition from one language to another — but you expect applications to change faster
Josh: no — on the web we expect things to keep working even if the author is long dead
MC: like a dead
Andy: I don't expect Betamax to work today
Josh: as a user, if it has good content — I want to watch
MC: that is a fault in the design
of Betamax
... it's very frustrating
RB: and it's a loss to civilisation
BS: media conversion occurs all the time — valuable content gets converted
MC: we'll still support legacy stuff
BS: you mean if possible
MC: no, actually support
Benoit: a new browser created today would have to be compatible all the way to 19991
MC: that's the point
BS: in the case of APIs you may find a better way to do it
RB: just change the name
BS: but then you don't have to support the old ones
RB: yes you do, there's content out there
MH: versioning helps
Josh, MC, Benoit, RB: no it doesn't
Benoit: versioning only works if
you can decide to support just one version
... or deprecate some versions
MH: it depends on the relationship between v1 and v2
Benoit: if v2 is very different from v1, it's not v2 — it's something different
BS: in principle I agree that
back-compat is important
... but there will be cases when we leave technologies
behind
... I think e.g. SMS will be replaced by SIP
MC: people will still want to access them
RB: and it's not a publishing format
BS: but I'm talking about an
API
... there'll be a new API, but still the old SMS API
... what if the device doesn't have the capability?
Benoit: it's a capability issue
RB: that's a capability issue, not a versioning issue
MH: what if a browser doesn't implement all the APIs?
RB: then it's not very useful
AB: can we come back to the P+C spec
MC: the @version is only for authors, it only identifies the version of the widget — it's just a string that humans can interpret
MH: I wanted to change the name of this attribute
MC: it's in line with how it's used
MH: it's different from how it is in other W3C specifications
AB: let's try to get some
closure
... does anybody object to the definition in the P+C?
MC: Marcin, what's your proposal?
MH: @widget-version
... I would like someone from the TAG to review this
... geolocation also define a version attribute on the
object
... for the specification version
AB: I don't see a conflict between that and us
MC: I can't find that on the API
MH: it was discussed today, also
with Anne
... if W3C is a spec vendor, then make it consistent
RB: that's already hopeless
<Zakim> MikeSmith, you wanted to comment
MS: the TAG is already having a
discussion about versioning
... co-ordination is not a constraint
... you don't want W3C to attempt to impose coherence at that
level of granularity — it would grind everything to a halt
AB: we're not going to find authority in the W3C that will tell us what to do
MS: the one point in the process
where that can happen is during transition
... at that point a formal objection can raise to the
Director
... and then the Director steps in, having collected
information from the TAG
AB: we don't want TimBL having to step in with the naming of an attribute
Josh: I'm fine with a change to make the text say in its first sentence that @version is the version of the widget, not of anything else
<anne> fwiw, geolocation does not specify version on the object
<anne> it is being considered by some, but that's not the same
<anne> (and I don't think it'll happen)
MH: I think that by doing this we
are breaking the architectural assumption of W3C
specifications
... elsewhere it is version of the specificaiton
... seen it in SVG, SML
thanks anne
MS: that's not true — e.g. HTML
RB: note that those examples do not have the same semantics
Josh: we shouldn't blacklist a word because it didn't work in other semantics — we want to use it for useful semantics
MC: how can we clarify this?
JK: it's already clear, I don't see what the confusion is
Josh: agreed
... I was confused by the attribute type description — can we
stick it after boolean, numeric (or alphabetically) so that it
doesn't jump out so much?
MC: yup
AB: third time, does anybody object to the way in which the @version attribute has been defined?
[None]
RESOLUTION: @version as defined in P+C LC is acceptable
AB: any other issues to raise today?
MC: thank you Marcin for your feedback, fixed a lot of stuff
AB: +1
... is MaxF going to submit comments?
MC: no, Lachlan and Anne are
<ArtB> AB: this one http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0789.html
AB: one extra topic, Scott Wilson brought up a number of good things, do we want to discuss some of them or is the on-list discussion enough to make progress?
MC: I think we're fine for P+C — a lot of his comments recently have been about A+E
AB: I have a cloudy crystal
ball
... modulo any major issues we should be ready to go to
CR
... what's your sense here Marcos?
MC: it's hard to judge, the
commenters I have lined up may bring up issues
... I think people on the WG have gone through it, hopefully
we've weeded out issues
... I plan to finish before I go on holiday (18th)
AB: Dan, will MWBP review?
DKA: hasn't MWBP come back?
AB: for LC1
DKA: I don't think there'll be any feedback for LC2
<scribe> ACTION: Josh to go through P+C one more time [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action05]
AB: I don't want to get a bunch of comments on the 20th — let's not extend the time, it's been in LC since the beginning of the year
<DKA> +1
RB: should we ask the SVG WG to review?
Josh: good idea
<scribe> ACTION: Robin to ask the SVG WG to review (before the 19th) [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action06]
<shepazu> noted
Benoit: what does vacation mean for the CR timing?
MC: probably July 1st
Benoit: can't decide on the 18th
MC: back on the 25th
... I should be able to ring in for the conf
AB: we could record a decision to
go forward on the 20th
... using a call for consensus
... if there are no objections, I'll then send a transition
request
DKA: we could do it on the 25th's call
AB: ok, let's do that
RB: I can fix the spec for pubrules if needed in MC's absence
MC: and it should be set to go anyway
AB: we'll cover testing
tomoroow
... PC, AOB?
Josh: exit criteria?
MS: what's the plan?
MC: I like the XBL2 criteria
AB: I like the DigSig
MC: it says the same thing, but wishy-washy
Josh: I like the second sentence about openness
AB: not sure it's clear enough
MS: we don't need to overanalyse
it, it's just about not getting the spec out based on some
in-house implementation that can't be verified
... needs some degree of distribution and general testing
Josh: the DigSig one requires 2 implementations of each test — not of the whole thing. Let's use the XBL2 version
AB: if the implementation ships as part of a phone, does it count
DKA: yes
RB: yes
... we don't need to overlegalise it, this very same WG will
decide when we agree to move out of CR
... this really is process wonking
AB: can we not have the same EC for each spec
RB: how about reusing DigSig, but
changing two implementations of *each* test but two of *all*
tests?
... it's a two word change
[AB summarises the proposal for MC]
<timeless_mbp> ... and demonstrated, according to the test suite, two interoperable implementations.
Dave: we could even drop "each test"
AB: anybody object to replacing " for each test" with nothing?
MC: the XBL2 one is better but I
can live with it
... I have made the change
RESOLUTION: the agreed-upon DigSig CR EC will be applied to P+C and to all subsequent specs in this WG
DKA: do we have a PAG call?
MS: yes
AB: the PAG is having weekly conferences as per process
BS: it had to do generally with
the purpose for the access element v the feature element
... there were two things I proposed
... 1) a @required flag
... you get only what you declare in the way it is defined,
which means that without prior knowledge that a specific domain
is going to be allowed, you won't find out until it doesn't
work
... you can't get access to things that may be useful but not
essential
... <feature> was designed around that, but not
<access> — which I find is similar in nature
... you could have alternate approaches if a netres is not
available
... I based access@required on the feature
RB: it's commented out, pushed out to v2
BS: why defer?
AB: I think the general reason why some of us felt we should put it off is because we hit LC around christmas last year, and we'd like to consider ourselves feature-complete
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
BS: but WARP has been moved out into a separate spec
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: is it assumed WARP is near LC?
<MikeSmith> trackbot, bye
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
AB: when we made that decision,
it was still in PC
... so does the decision move with it?
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
<MikeSmith> trackbot, status
<trackbot> This channel is not configured
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
AB: the idea was that WARP should
move at warp speed
... I suggest that the same rationale applies
... we don't want any new features
MC: I still don't see much use for these attributes, so from Opera's point of view we don't see them as that useful
JK: I'm indifferent about
@required, but @duration is disconcerting
... I see a lot of echo of J2ME and the result of that is when
these values were used and applied to mutiple different APIs it
very quickly turns into excessive prompting
<MikeSmith> trackbot, init
<MikeSmith> trackbot, status
<trackbot> This channel is not configured
JK: that's a UX killer — if we bring that into <access> where the granularity is a URL, and you have several of these, you're going to get more prompting, and a dreadful UX
<MikeSmith> trackbot. leave
<MikeSmith> trackbot, leave
RT: I agree, you're implying UX with prompting — we don't want to imply UX, that's an implementation thing
MH: consolidation of the prompts?
<MikeSmith> trackbot, associate this channel with webapps
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<MikeSmith> trackbot, associate this channel with webapps
<trackbot> Associating this channel with webapps...
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
MH: this is an important factor
BS: the purpose is not to mandate
a UI/UX
... obviously apps have to be designed or vetted to access some
features
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
<ArtB> Bryan's email: http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/att-0844/00-part
BS: the purpose of this disclosure is not to promote a given security model
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
<MikeSmith> trackbot, leave
BS: we will eventually have a process of alignement
<trackbot> Sorry... I don't know anything about this channel
<trackbot> If you want to associate this channel with an existing Tracker, please say 'trackbot, associate this channel with #channel' (where #channel is the name of default channel for the group)
<MikeSmith> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: we see this process of prompting as essential
<MikeSmith> trackbot, status?
<trackbot> This channel is not configured
BS: but this is just like
feature@required
... this is about what the widget needs to be able to do
MC: even if @required is going to be useless because the URL might be unavailable
BS: but you can still have a policy
MC: yeah, but I think it's
overkill
... <access> says what you want to access, and then it
might but unavailable
... so you're already handling that case
BS: but the widget won't install
RB: we don't say whether the widget gets installed or not
MC: you know access@uri
... if it's not allowed to access something inside the range of
URIs, the required doesn't change anything there
... on feature it's different but I could live with dropping it
there
<MikeSmith> action-1
errrrr
<scribe> ACTION: RB to send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [recorded in http://www.w3.org/2009/06/09-wam-minutes.html#action07]
<trackbot> Created ACTION-354 - Send Larry a proper response about "thismessage" and how it relates to Widget URI scheme http://www.rfc-editor.org/rfc/rfc2557.txt [on Robin Berjon - due 2009-06-16].
sorry, had to undrop it
MC: the request would just fail
BS: but with @reuiqred you can
check that by policy
... you could implement APIs on the web represented as URIs
much more flexibly, but they should be equal citizen with
feature
MC: required on feature is a legacy from when we had fallback — this has gone so it could go too
RB: if we drop @required on feature we have to go back to LC
BS: if you discover incompatibility earlier, you have a better UX
Josh: wrong, users get pissed
because they can't install the widget that their friend
has
... if it bails out too early I can't use it
... I can show examples of this
BS: I would prefer to not even
offer that to download based on capability
... we can do this in PC, or we can do this externally
MC: why do we assume that there will be different policies for different devices
BS: we do policy per context, in MIDP and native
MC: which are very unsuccessful
<dom> trackbot, associate this channel with #webapps
<trackbot> Associating this channel with #webapps...
BS: some people chage, some people don't
AB: the more we talk about policy, the more I think it's a DAP problem
RB: thank you Art, you'll pay for that
<JereK> +1
<dom> trackbot, status?
<trackbot> This channel is not configured
<dom> ACTION-1?
<trackbot> ACTION-1 -- Doug Schepers to find All Open Issues For DOM3 Events and Update the Specification -- due 2009-03-18 -- OPEN
<trackbot> http://www.w3.org/2008/webapps/track/actions/1
AB: I'm not hearing a lot of
support within this WG to do it here
... there's an opportunity to submit furhter comments when FPWD
is out
... WARP isn't in LC, so in theory it's open to features
emphasis on theory
AB: I recommend ending the discussion now, and discussing when the FPWD is out
MC: in the future, there's only
ever going to be one policy
... for all devices
RB: developers certainly would prefer that
RESOLUTION: Policy gets discussed in DAP
MC: we can add it in a separate spec
BS: we'd like to avoid the overhead of addiotinal spec
Josh: we'd like to avoid the overhead of extra attributes that turn out to be useless
the WG opens a bet about the future
ADJOURNED
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Marcos/OMTP/ Succeeded: s/some way for regulating user access/some way of regulating access for the user/ Succeeded: s/down, please/done, please/ Succeeded: s/[this]/just mixing redirects and origin determination/ Succeeded: s/fix dns/fix the web/ Succeeded: s/Frederic/Steve/ Succeeded: s/Scribe: Marcos/Scribe+ Marcos/ Succeeded: s/BJ/RB/ Succeeded: s/tltr/tlr/ Succeeded: s/MC/MH/ Found Scribe: ArtB Inferring ScribeNick: ArtB Found ScribeNick: ArtB Found Scribe: Art, Bryan Found Scribe: Art, Mike Found ScribeNick: MikeSmith Found ScribeNick: Bryan Found Scribe: Dan Found ScribeNick: DKA Found ScribeNick: Marcos Found ScribeNick: darobin Scribes: ArtB, Art, Bryan, Art, Mike, Dan ScribeNicks: ArtB, MikeSmith, Bryan, DKA, Marcos, darobin Default Present: Thomas, fjh, SteveLewontin, +44.163.567.aaaa, [London] Present: Benoit Mike Josh Jere Art Robin Marcos AndyB DanA David Laura Marcin Bryan Magnus Richard Frederick Thomas SteveL Agenda: http://www.w3.org/2008/webapps/wiki/WidgetsLondonJune2009#Agenda Found Date: 09 Jun 2009 Guessing minutes URL: http://www.w3.org/2009/06/09-wam-minutes.html People with action items: art josh rb robin send[End of scribe.perl diagnostic output]