See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 26 March 2009
AB: I posted the agenda on March
25
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0926.html
Note DigSig is not on today's agenda.
... Are there any change requests?
FH: want to add DigSig namespaces
AB: OK but will limit the
time
... any other requests?
[None]
AB: any short announcements? I don't have any.
[ None ]
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> 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
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: <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?
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
AB: last week the <access>
element was noted as an open issue that must be addressed
before we can publish a new LCWD. 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?
MC: I am researching how to
address this
... looking at what Opera does
<Marcos> I need to align it with 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. 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
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) http://dev.w3.org/2006/waf/widgets/#the-update-element
and Step 7
http://dev.w3.org/2006/waf/widgets/#step-7-process-the-configuration-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?
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
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? 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
AB: Thomas and Marcos have exchanged some emails about this http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0883.html What is the status and what specifically needs to be done to address the issue?
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?
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: 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> 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 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!
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
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/fixed it/will fix it/ Succeeded: s/<status>/<access>/ Succeeded: s/.AB/AB/ Succeeded: s/imple/simple/ Found ScribeNick: ArtB Found Scribe: Art Present: Art Thomas Frederick Mark Andy Robin Arve Marcos Regrets: Jere Bryan Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0926.html Found Date: 26 Mar 2009 Guessing minutes URL: http://www.w3.org/2009/03/26-wam-minutes.html People with action items: arve[End of scribe.perl diagnostic output]