The minutes from the March 26 Widgets voice conference are available
at the following and copied below:
<http://www.w3.org/2009/03/26-wam-minutes.html>
WG Members - if you have any comments, corrections, etc., please send
them to the public-webapps mail list before 2 April 2009 (the next
Widgets voice conference); otherwise these minutes will be considered
Approved.
-Regards, Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
26 Mar 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0926.html
See also: [3]IRC log
[3] http://www.w3.org/2009/03/26-wam-irc
Attendees
Present
Art, Thomas, Frederick, Mark, Andy, Robin, Arve, Marcos
Regrets
Jere, Bryan
Chair
Art
Scribe
Art
Contents
* [4]Topics
1. [5]Review and tweak agenda
2. [6]Announcements
3. [7]DigSig
4. [8]P&C spec: L10N model
5. [9]P&C spec: status of <access> element:
6. [10]P&C spec: <update> element given Apple's patent
disclosure
7. [11]P&C spec: step 7 - need to add <preference> element and
the <screenshot> element;
8. [12]P&C spec: XML Base
9. [13]A&E spec
10. [14]Window Modes spec
* [15]Summary of Action Items
_________________________________________________________
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 26 March 2009
Review and tweak agenda
AB: I posted the agenda on March 25
[16]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/09
26.html Note DigSig is not on today's agenda.
... Are there any change requests?
[16] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0926.html
FH: want to add DigSig namespaces
AB: OK but will limit the time
... any other requests?
[None]
Announcements
AB: any short announcements? I don't have any.
[ None ]
DigSig
AB: go ahead Frederick
FH: I made a few changes
... checker complained
MC: will fix it
FH: namespace question
... is it OK to not use date
TR: I need to check the namespace policy
<tlr> [17]http://www.w3.org/2005/07/13-nsuri
[17] http://www.w3.org/2005/07/13-nsuri
RB: namespace policy should permit this
TR: I don't see any problems; we can go ahead
FH: then I think we're all set
MC: agreed
AB: the DigSig WD should be published early next week
P&C spec: L10N model
AB: one of the open issues is if the P&C's localization model should
be one master config file only versus a master config file plus
locale-specific config files to override definitions in the master
config file. Marcos created lists of advantages and disadvantages of
both models. Some people have expressed their preference. The tally
appears to be: Only one: Marcos; One Plus: Josh, Benoit; Can Live
With Either: Jere. The thread is here:
<[18]http://lists.w3.org/Archi
... I would like to get consensus i.e. a resolution on this today
and a gentle reminder that "I Can Live With It" will help us get the
next LCWD published. Let's start with Marcos - do you see a single
model that addresses everyone's concerns?
[18] http://lists.w3.org/Archi
MC: the new model doesn't address the concern where multiple
localizers are involved in the process pipeline
... the new model is easier to implement
... agree the config file could grow to an un-manageable size
... the I18N WG said the new model is OK
... I think we could merge the models
BS: I don't understand the merge model Marcos
MC: have the main config file but if the app has lots of localized
data that data can be put in separate files
AB: any other comments?
<w3c_> when using both models there would need a sort of precedence
of some sort so that 2 information do not overlap
RB: so is the idea to have a single file for v1.0 and then in v1.*
move to support the old model
MC: yes, that is true
<darobin> RB: I think it makes sense to start with something simple
and only add the more advanced features if we need them later
MC: the model is to use a single config doc for 1.0
... inside that file the xml:lang attr is used to localize specific
elements and attrs
... in subsequent version of P+C we add support for locale-specific
conf files
AB: is this right Marcos?
MC: yes
AB: any comments about this evolution path
... Note that timeless is not on the call
... He objected to the new model but did not include any rationale
for his objection
... Benoit, what are your thoughts on this evolution proposal?
BS: I think I can live with it
... I do think localizers having their separate files is better
... but having just one config file wil be easier for the developer
AB: I think we have consensus to go forward with Marcos' proposal
... draft resolution: for v1.0 we will use the new l10n model
proposed by Marcos and consider multiple locale-specific config
files for the next version
... any objections?
[ None ]
RESOLUTION: for v1.0 we will use the new L10N model proposed by
Marcos and consider multiple locale-specific config files for the
next version
P&C spec: status of <access> element:
AB: last week the <access> element was noted as an open issue that
must be addressed before we can publish a new LCWD.
[19]http://dev.w3.org/2006/waf/widgets/#the-access-element If I
recall correctly, no one volunteered to submit any related inputs.
The note in the ED says "ISSUE: This element is currently under
review. A new proposal will be available in the next few days that
will provide the ability to list which URIs can be accessed.".
... Marcos, what is the status and what specific inputs are needed?
[19] http://dev.w3.org/2006/waf/widgets/#the-access-element
MC: I am researching how to address this
... looking at what Opera does
<Marcos> I need to align it with
[20]http://homer.w3.org/~connolly/projects/urlp/raw-file/008373680ca
e/wah5/draft.html
[20] http://homer.w3.org/~connolly/projects/urlp/raw-file/
008373680cae/wah5/draft.html
MC: but we probably will want to do something a bit different
... the above is by Dan Connolly
TR: what alignment with DC's draft is needed?
MC: need to align with terminology
... need to break up the scheme parts to diferent attrs
... e.g. port can be a list
TR: this is similar to some work in POWDER WG
... wonder if this needs to depend on the URLs in DC's work
... but we can take it to e-mail
... doing this should take a week or two and will require some
changes
RB: can we please get a pointer to POWDER work?
TR: will get one; not sure if there needs to be a dependency
... we should take this to e-mail
MP: we previously discussed a hybrid approach
... and then define some precedence rules if there are conflicts in
host elements
... for v1 can we just go with URI
... and if a hybrid approach really is needed we do that in a
subsequent version of the spec
... What do you think about that approach?
MC: could be a prob in some use cases
... some web apps have many subdomains
... then those couldn't be accessed
RB: but could use *.foo
MC: yes, that's an option
<darobin> RB: e.g. [21]http://*.googlemaps.com
[21] http://*.googlemaps.com/
AB: any last comments before this discussion moves to the mail list
MC: if we use wildcards, it opens a different set of questions
... e.g. what part of the scheme are "*" permitted
RB: typically, don't need too many ports
... want to start with something simple for v1
... and possibly ask for more feedback
AB: please take the discussion to the mail list
... MC, can you make a short proposal on the mail list?
MC: yes I will
... re wildcarding, CORS tried this and it didn't really work
P&C spec: <update> element given Apple's patent disclosure
AB: Apple's disclosure raises the question "what, if any, changes
must be made to the P&C spec?" where one major concern is if P&C has
a dependency on Updates. There appear to be two relevant pieces of
text: Section 7.14 (<update> element)
[22]http://dev.w3.org/2006/waf/widgets/#the-update-element and Step
7
[23]http://dev.w3.org/2006/waf/widgets/#step-7-process-the-configura
tion-document.
... My take is that Section 7.14 is OK as written given what we know
today (PAG hasn't even had its first meeting). The element's
processing in Step 7 could be qualified with something like "this
step is only performed if the UA implements [Widgets Updates] but I
can live with the existing text.
... One other option is to put a Warning in 7.14 e.g. "Warning: this
feature may be removed because ...".
... what are people's thoughts on this?
[22] http://dev.w3.org/2006/waf/widgets/#the-update-element
[23] http://dev.w3.org/2006/waf/widgets/#step-7-process-the-
configuration-document.
BS: without any info from the PAG, I think we should keep it and add
some type of warning
TR: is the question, how far can the spec go given the PAG?
... I think the group cannot go beyond LC but will verify with Rigo
AB: the syntax is in the PC spec but the proc model is in the
Updates spec
MC: yes that is correct
... we could remove <update> element from P+C and define it in the
Updates spec
AB: any comments on Marcos' proposal?
... I like that proposal
BS: I would be opposed to it
TR: I will discuss this Rigo and cc member-webapps
<Benoit> but I do not want to hold the P&C spec with this
TR: I can understand the concern about a normative ref for a spec
that may be stalled
AB: we will wait for some feedback from TR and Rigo before we
implement MC's proposal
P&C spec: step 7 - need to add <preference> element and the
<screenshot> element;
AB: last week <preference> and <screenshot> were noted as needing
work. I believe Robin agreed to help with this. What is the status
and plan?
[24]http://dev.w3.org/2006/waf/widgets/#step-7-process-the-configura
tion-document
[24] http://dev.w3.org/2006/waf/widgets/#step-7-process-the-
configuration-document
RB: I haven't made a lot of progress on this
MC: I will try to finish this by tomorrow
... I have been blocked by the consensus on the L10N model
... but now that we have that consensus, I can make the appor
changes
P&C spec: XML Base
AB: Thomas and Marcos have exchanged some emails about this
[25]http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/08
83.html What is the status and what specifically needs to be done to
address the issue?
[25] http://lists.w3.org/Archives/Public/public-webapps/
2009JanMar/0883.html
MC: this relates to the L10N model too
... the xml:lang value needs to match the name of a localized folder
... TR is wondering if XML base is the right solution for this
... there are some other related issues too; I've been talking to
Robin and others in Opera about this
... Not having a URI scheme for widgets cause problems too
... ZIP relative paths are not URIs
TR: we want a model to make refs from within the html
... but mapping URI refs to something else
... using XML base is not going to help
... as it confuses the left and right sides of the mapping
... The spec lang MC wrote redfines XML base
MC: I still want to try to solve this with XML Base
... our solution will have to work with HTML base
TR: if there is a URI scheme defined that points at things within
the widget
... then we can use that URI scheme throughout
MC: yes
TR: does the base paramter sit on the URI side of the mapping or the
other side
... similar to some questions we had about References in DigSig
... struggling with a missing design decision
... there are two things: uri ref and the other is paths to the zip
... think most things should be in URI side but some things should
be on the zip side
... Need to get some consistency in the various specs
RB: agree we must solve this problem
<tlr> RB: metadata files will feel more comfortable in URI space
<tlr> TR: This is another instance of the URI discussion. We have
some things that live in URI space. We have some things that live in
Zip path space. We need to do a translation between the two and say
where that happens.
<darobin> RB: we have to solve this anyway for the content of the
widgets (HTML, SVG), so since we need to solve it, and since it
would be more comfortable to use URIs in config.xml we ought to
solve it once and use it everywhere
<tlr> TR: Right now, we're reinventing that translation over and
over again. That way lies madness
AB: other than "take this to the mail list", who is going to do what
to help us get closure here?
... any last comments?
A&E spec
AB: the latest ED of the A&E spec includes many Red Block Issues.
I'd like to go thru as many of them at a high level and for each of
them get a sense of what specific inputs are needed and the plan to
get those inputs. Latest ED is:
[26]http://dev.w3.org/2006/waf/widgets-api/
[26] http://dev.w3.org/2006/waf/widgets-api/
Arve: Marcos, the latest ED says 25 March but I don't think it is
the latest version
AB: yes, I was wondering the same thing
Arve: should we go thru all of the Red Blocks?
AB: I want to understand what needs to be done
Arve: re Window issue
... who can talk to HTML WG
RB: I think Window will be split out as soon as an Editor is
identified
MC: but no one has agreed to be the Editor
AB: so what does this mean in terms of the progression of this spec?
MC: I don't think we need a depedency on the Window spec
... We can just add some text about the "top level ... "
Arve: yes, we can make it informative ref
<darobin>
[27]http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window
[27] http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window
TR: agree, it can be Informative ref
AB: do we consensus the dependency is an Informative ref?
Arve: yes
... I can re-write this Red Block
... I only want a DOM 3 Core ref and Widget ref but nothing else
... and XHR as is done already
AB: any objections to Arve's proposal?
RB: that's OK; could even make the dependencies in a sep doc
[ No objections ]
AB: next, Section 5 - Resolving DOM Nodes
Arve: we don't need to say anything about the URI scheme here
... I propose removing this section
... and be a bit more specific about how URIs are used where
appropriate in the spec
AB: so you propose remove seciton 5?
Arve: yes
AB: any objections to that proposal?
[ None ]
AB: next is 7.3 - identifier attr
... "Issue: how does an author access the widget's id as declared in
the config document? Also, what happens if this is not unique? How
is uniqueness assured?
Arve: not sure what we should do here
... my proposal is to use an equivalent element in the config file
and to use that
AB: any questions or concerns about that proposal?
... Marcos, what element would be used?
MC: not sure
AB: so the action for you Arve is to check the config file and come
back with a proposal?
Arve: yes
<scribe> ACTION: Arve create a proposal for the A+E's section 7.3
Red Block issue re the identifier attribute [recorded in
[28]http://www.w3.org/2009/03/26-wam-minutes.html#action01]
<trackbot> Created ACTION-325 - Create a proposal for the A+E's
section 7.3 Red Block issue re the identifier attribute [on Arve
Bersvendsen - due 2009-04-02].
TR: is this just needed at runtime?
... is this put in the base URI
... want to understand what is needed for
Arve: we do not need to define how it is used
... at runtime, a unique id is generated
... and randomizes the base uri
TR: this seems like an simple detail
... want to understand how it is used by widget instance
MC: yes, what would a developer use it for?
TR: what is this attr used for?
<tlr> it might be that the attribute you really want is origin
TR: I don't think I'm getting an answer that substantiates its need
MC: yes, I agree with TLR
<tlr> but that's defined elsewhere ;)
Arve: perhaps you're right
BS: what about cross-widget comm?
MC: not sure we want to include it for that use Benoit
TR: I propose we remove identifier attribute
Arve: if wanted to use post message, could use this
<tlr> sure
AB: let's stop discussion and take this to the mail list
<tlr> AB: raise question in response to Arve's draft on the mailing
list
<tlr> TR: sure
Arve: I will submit proposals for all of the Red Block issues
starting with the one in Section 7.8
AB: that would be excellent Arve!
Window Modes spec
AB: what is the status and next steps?
<arve> anyone who wants to derive an origin url, could do so using
document.domain
MC: we don't have any new status to report
... we need an editor
AB: do we have a skeleton doc?
... I mean anything checked into CVS?
MC: No
AB: any volunteers to drive this?
<tlr> arve, nooo
RB: I will take it!
... it may be about 10 days though before I can start working on it
AB: excellent Robin!
<fjh> fixes in widget signature complete, apart from latest comments
received from Bondi and date of document
AB: any other hot topics
... Meeting Adjourned
Summary of Action Items
[NEW] ACTION: Arve create a proposal for the A+E's section 7.3 Red
Block issue re the identifier attribute [recorded in
[29]http://www.w3.org/2009/03/26-wam-minutes.html#action01]
[End of minutes]
