13:00:15 <RRSAgent> RRSAgent has joined #wam
13:00:15 <RRSAgent> logging to http://www.w3.org/2009/03/26-wam-irc
13:00:22 <ArtB> ScribeNick: ArtB
13:00:25 <ArtB> Scribe: Art
13:00:28 <ArtB> Chair: Art
13:00:33 <ArtB> Date: 26 March 2009
13:00:41 <ArtB> Meeting: Widgets Voice Conference
13:00:42 <tlr> zakim, call thomas-781
13:00:42 <Zakim> ok, tlr; the call is being made
13:00:44 <Zakim> +Thomas
13:00:47 <ArtB> Agenda: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0926.html
13:01:04 <ArtB> Regrets: Jere
13:01:12 <ArtB> Present: Art, Thomas, Frederick
13:01:44 <ArtB> Regrets+ Bryan
13:01:54 <Zakim> + +1.919.536.aaaa
13:02:02 <Zakim> +Mark
13:02:03 <Zakim> +??P9
13:02:10 <darobin> Zakim, P9 is me
13:02:10 <Zakim> sorry, darobin, I do not recognize a party named 'P9'
13:02:11 <ArtB> Present+ Mark
13:02:13 <arve> arve has joined #wam
13:02:15 <ArtB> Present+ Andy
13:02:27 <ArtB> Present+ Robin
13:02:29 <mpriestl> mpriestl has joined #wam
13:02:56 <Zakim> + +47.23.69.aabb
13:03:00 <arve> zakim, aabb is me
13:03:00 <Zakim> +arve; got it
13:03:04 <ArtB> RRSAgent, make log public
13:03:12 <ArtB> Present+ Arve
13:03:51 <Zakim> +[IPcaller]
13:03:54 <ArtB> RRSAgent, make minutes
13:03:54 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-wam-minutes.html ArtB
13:04:07 <ArtB> Present+ Marcos
13:04:12 <arve> zakim, whoi is making noise?
13:04:12 <Zakim> I don't understand your question, arve.
13:04:14 <darobin> Zakim, who's making noise?
13:04:16 <arve> zakim, who is making noise?
13:04:32 <Zakim> darobin, listening for 10 seconds I heard sound from the following: fjh (5%), Art_Barstow (58%), darobin (65%), arve (15%), [IPcaller] (35%)
13:04:38 <ArtB> Topic: Review and tweak agenda
13:04:39 <darobin> Zakim, mute me me
13:04:39 <Zakim> I don't understand 'mute me me', darobin
13:04:43 <w3c_> w3c_ has joined #wam
13:04:43 <darobin> Zakim, mute me
13:04:46 <Zakim> arve, listening for 10 seconds I heard sound from the following: Art_Barstow (63%), darobin (66%)
13:04:46 <ArtB> 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.
13:04:48 <Zakim> darobin should now be muted
13:04:56 <ArtB> ... Are there any change requests?
13:04:57 <fjh> q+
13:05:02 <fjh> zakim, unmute me
13:05:02 <Zakim> fjh should no longer be muted
13:05:16 <ArtB> FH: want to add DigSig namespaces
13:05:45 <ArtB> AB: OK but will limit the time
13:05:54 <ArtB> AB: any other requests?
13:05:55 <ArtB> [None]
13:06:08 <ArtB> Topic: Announcements
13:06:14 <ArtB> AB: any short announcements? I don't have any.
13:06:19 <ArtB> [ None ]
13:06:23 <ArtB> Topic: DigSig
13:06:36 <ArtB> AB: go ahead Frederick
13:06:41 <ArtB> FH: I made a few changes
13:06:56 <ArtB> ... checker complained
13:07:00 <ArtB> MC: fixed it
13:07:11 <ArtB> FH: namespace question
13:07:18 <ArtB> ... is it OK to not use date
13:07:30 <ArtB> TR: I need to check the namespace policy
13:07:33 <tlr> http://www.w3.org/2005/07/13-nsuri
13:07:33 <darobin> Zakim, unmute me
13:07:33 <Zakim> darobin should no longer be muted
13:07:54 <ArtB> RB: namespace policy should permit this
13:08:08 <ArtB> TR: I don't see any problems; we can go ahead
13:08:14 <ArtB> FH: then I think we're all set
13:08:18 <ArtB> MC: agreed
13:08:25 <fjh> zakim, mute me
13:08:25 <Zakim> fjh should now be muted
13:08:52 <ArtB> AB: the DigSig WD should be published early next week
13:08:54 <ArtB> Topic: P&C spec: L10N model
13:09:08 <ArtB> 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
13:09:14 <Zakim> + +45.29.aacc
13:10:22 <ArtB> AB: 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?
13:11:35 <ArtB> MC: the new model doesn't address the concern where multiple localizers are involved in the process pipeline
13:11:54 <ArtB> ... the new model is easier to implement
13:12:26 <ArtB> ... agree the config file could grow to an un-manageable size
13:12:40 <ArtB> ... the I18N WG said the new model is OK
13:12:54 <ArtB> ... I think we could merge the models
13:13:09 <ArtB> BS: I don't understand the merge model Marcos
13:13:38 <ArtB> MC: have the main config file but if the app has lots of localized data that data can be put in separate files
13:13:46 <MoZ> MoZ has joined #wam
13:14:58 <abraun> abraun has joined #wam
13:15:26 <ArtB> AB: any other comments?
13:15:40 <w3c_> when using both models there would need a sort of precedence of some sort so that 2 information do not overlap
13:16:05 <ArtB> RB: so is the idea to have a single file for v1.0 and then in v1.* move to support the old model
13:16:15 <ArtB> MC: yes, that is true
13:16:56 <darobin> RB: I think it makes sense to start with something simple and only add the more advanced features if we need them later
13:17:02 <ArtB> MC: the model is to use a single config doc for 1.0 
13:17:20 <ArtB> ... inside that file the xml:lang attr is used to localize specific elements and attrs
13:17:36 <fjh> s/fixed it/will fix it/
13:18:17 <ArtB> ... in subsequent version of P+C we add support for locale-specific conf files
13:18:32 <ArtB> AB: is this right Marcos?
13:18:35 <ArtB> MC: yes
13:19:18 <ArtB> AB: any comments about this evolution path
13:19:29 <ArtB> ... Note that timeless is not on the call
13:19:36 <w3c_> w3c_ has left #wam
13:19:54 <ArtB> ... He objected to the new model but did not include any rationale for his objection
13:20:15 <ArtB> ... Benoit, what are your thoughts on this evolution proposal?
13:20:22 <ArtB> BS: I think I can live with it
13:20:38 <ArtB> ... I do think localizers having their separate files is better
13:21:02 <ArtB> ... but having just one config file wil be easier for the developer
13:21:39 <ArtB> AB: I think we have consensus to go forward with Marcos' proposal
13:22:11 <w3c> w3c has joined #wam
13:22:24 <ArtB> AB: 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
13:22:32 <ArtB> AB: any objections?
13:22:34 <ArtB> [ None ]
13:23:30 <ArtB> 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
13:23:38 <ArtB> Topic: P&C spec: status of <access> element:
13:23:47 <ArtB> AB: last week the <status> 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.".
13:24:09 <darobin> s/<status>/<access>/
13:24:27 <mpriestl> q+
13:24:37 <ArtB> AB: Marcos, what is the status and what specific inputs are needed?
13:24:55 <ArtB> MC: I am researching how to address this
13:25:01 <ArtB> ... looking at what Opera does
13:25:14 <Marcos> I need to align it with http://homer.w3.org/~connolly/projects/urlp/raw-file/008373680cae/wah5/draft.html
13:25:15 <ArtB> ... but we probably will want to do something a bit different
13:25:33 <ArtB> ... the above is by Dan Connolly
13:25:43 <tlr> q+
13:26:16 <ArtB> TR: what alignment with DC's draft is needed?
13:26:25 <ArtB> MC: need to align with terminology
13:26:59 <ArtB> ... need to break up the scheme parts to diferent attrs
13:27:06 <ArtB> ... e.g. port can be a list
13:27:45 <ArtB> TR: this is similar to some work in POWDER WG
13:28:13 <ArtB> ... wonder if this needs to depend on the URLs in DC's work
13:28:20 <ArtB> ... but we can take it to e-mail
13:28:52 <ArtB> ... doing this should take a week or two and will require some changes
13:29:17 <ArtB> RB: can we please get a pointer to POWDER work?
13:29:30 <ArtB> TR: will get one; not sure if there needs to be a dependency
13:29:38 <ArtB> ... we should take this to e-mail
13:30:45 <ArtB> MP: we previously discussed a hybrid approach
13:31:19 <ArtB> ... and then define some precedence rules if there are conflicts in host elements
13:31:36 <ArtB> ... for v1 can we just go with URI 
13:31:57 <ArtB> ... and if a hybrid approach really is needed we do that in a subsequent version of the spec
13:32:11 <ArtB> ... What do you think about that approach?
13:32:22 <ArtB> MC: could be a prob in some use cases
13:32:32 <ArtB> ... some web apps have many subdomains
13:32:47 <ArtB> ... then those couldn't be accessed
13:32:58 <ArtB> RB: but could use *.foo 
13:33:10 <ArtB> MC: yes, that's an option
13:33:12 <darobin> RB: e.g. http://*.googlemaps.com
13:33:33 <Zakim> -[IPcaller]
13:34:00 <Zakim> +??P2
13:34:14 <ArtB> AB: any last comments before this discussion moves to the mail list
13:35:05 <ArtB> MC: if we use wildcards, it opens a different set of questions
13:35:16 <ArtB> ... e.g. what part of the scheme are "*" permitted
13:35:39 <ArtB> RB: typically, don't need too many ports
13:36:07 <ArtB> ... want to start with something simple for v1
13:36:18 <ArtB> ... and possibly ask for more feedback
13:37:14 <ArtB> AB: please take the discussion to the mail list
13:37:49 <ArtB> ... MC, can you make a short proposal on the mail list?
13:37:54 <ArtB> MC: yes I will
13:38:09 <ArtB> ... re wildcarding, CORS tried this and it didn't really work
13:38:15 <ArtB> Topic: P&C spec: <update> element given Apple's patent disclosure
13:38:53 <ArtB> 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.
13:39:29 <Zakim> - +1.919.536.aaaa
13:39:34 <ArtB> AB: 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.
13:40:16 <ArtB> AB: One other option is to put a Warning in 7.14 e.g. "Warning: this feature may be removed because ...".
13:40:54 <ArtB> AB: what are people's thoughts on this?
13:41:28 <ArtB> BS: without any info from the PAG, I think we should keep it and add some type of warning
13:42:13 <ArtB> TR: is the question, how far can the spec go given the PAG?
13:42:37 <ArtB> ... I think the group cannot go beyond LC but will verify with Rigo
13:42:44 <Zakim> + +1.919.536.aadd
13:43:44 <ArtB> AB: the syntax is in the PC spec but the proc model is in the Updates spec
13:43:50 <ArtB> MC: yes that is correct
13:44:20 <ArtB> MC: we could remove <update> element from P+C and define it in the Updates spec
13:44:34 <ArtB> AB: any comments on Marcos' proposal?
13:44:40 <ArtB> AB: I like that proposal
13:44:49 <ArtB> BS: I would be opposed to it
13:45:07 <ArtB> TR: I will discuss this Rigo and cc member-webapps
13:45:08 <Benoit> but I do not want to hold the P&C spec with this
13:45:48 <ArtB> TR: I can understand the concern about a normative ref for a spec that may be stalled
13:46:13 <ArtB> AB: we will wait for some feedback from TR and Rigo before we implement MC's proposal
13:46:27 <ArtB> Topic: P&C spec: step 7 - need to add <preference> element and the <screenshot> element; 
13:46:39 <ArtB> 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
13:47:20 <ArtB> RB: I haven't made a lot of progress on this
13:47:42 <ArtB> MC: I will try to finish this by tomorrow
13:47:55 <ArtB> ... I have been blocked by the consensus on the L10N model
13:48:10 <ArtB> ... but now that we have that consensus, I can make the appor changes
13:48:23 <ArtB> Topic: P&C spec: XML Base
13:48:33 <ArtB> 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?
13:49:16 <ArtB> MC: this relates to the L10N model too
13:49:32 <MoZ> MoZ has joined #wam
13:50:07 <ArtB> ... the xml:lang value needs to match the name of a localized folder
13:50:29 <ArtB> ... TR is wondering if XML base is the right solution for this
13:51:07 <ArtB> ... there are some other related issues too; I've been talking to Robin and others in Opera about this
13:51:25 <ArtB> ... Not having a URI scheme for widgets cause problems too
13:51:36 <ArtB> ... ZIP relative paths are not URIs
13:52:24 <ArtB> TR: we want a model to make refs from within the html
13:52:40 <ArtB> ... but mapping URI refs to something else
13:52:53 <ArtB> ... using XML base is not going to help
13:53:09 <ArtB> ... as it confuses the left and right sides of the mapping
13:53:42 <ArtB> ... The spec lang MC wrote redfines XML base
13:54:06 <ArtB> MC: I still want to try to solve this with XML Base
13:54:42 <ArtB> ... our solution will have to work with HTML base
13:55:06 <ArtB> TR: if there is a URI scheme defined that points at things within the widget
13:55:16 <ArtB> ... then we can use that URI scheme throughout
13:55:18 <ArtB> MC: yes
13:56:33 <ArtB> TR: does the base paramter sit on the URI side of the mapping or the other side
13:56:51 <ArtB> ... similar to some questions we had about References in DigSig
13:57:12 <ArtB> ... struggling with a missing design decision
13:58:23 <ArtB> TR: there are two things: uri ref and the other is paths to the zip
13:59:13 <ArtB> ... think most things should be in URI side but some things should be on the zip side
13:59:25 <asledd> asledd has joined #wam
13:59:27 <ArtB> ... Need to get some consistency in the various specs
13:59:39 <ArtB> RB: agree we must solve this problem
14:00:00 <tlr> RB: metadata files will feel more comfortable in URI space
14:00:28 <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.
14:00:37 <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
14:00:39 <tlr> TR: Right now, we're reinventing that translation over and over again. That way lies madness
14:01:58 <ArtB> .AB: other than "take this to the mail list", who is going to do what to help us get closure here?
14:02:21 <darobin> s/.AB/AB/
14:02:29 <ArtB> AB: any last comments?
14:02:45 <ArtB> Topic: A&E spec
14:02:59 <ArtB> 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/
14:04:06 <ArtB> Arve: Marcos, the latest ED says 25 March but I don't think it is the latest version
14:04:15 <ArtB> AB: yes, I was wondering the same thing
14:04:25 <fjh> fjh has joined #wam
14:05:31 <ArtB> Arve: should we go thru all of the Red Blocks?
14:05:41 <ArtB> AB: I want to understand what needs to be done
14:05:54 <ArtB> Arve: re Window issue
14:06:50 <ArtB> ... who can talk to HTML WG
14:07:06 <ArtB> RB: I think Window will be split out as soon as an Editor is identified
14:07:15 <ArtB> MC: but no one has agreed to be the Editor
14:07:40 <ArtB> AB: so what does this mean in terms of the progression of this spec?
14:07:55 <ArtB> MC: I don't think we need a depedency on the Window spec
14:08:21 <ArtB> ... We can just add some text about the "top level ... "
14:08:29 <ArtB> Arve: yes, we can make it informative ref
14:08:39 <darobin> http://www.w3.org/TR/SVGMobile12/svgudom.html#dom__Window
14:08:57 <ArtB> TR: agree, it can be Informative ref
14:09:21 <ArtB> AB: do we consensus the dependency is an Informative ref?
14:10:14 <ArtB> Arve: yes
14:10:40 <Benoit> Benoit has joined #wam
14:10:56 <ArtB> ... I can re-write this Red Block
14:11:14 <ArtB> ... I only want a DOM 3 Core ref and Widget ref but nothing else
14:11:30 <ArtB> ... and XHR as is done already
14:11:32 <Benoit> Benoit has joined #wam
14:11:51 <ArtB> AB: any objections to Arve's proposal?
14:12:09 <ArtB> RB: that's OK; could even make the dependencies in a sep doc
14:12:12 <Benoit> Benoit has joined #wam
14:12:19 <ArtB> [ No objections ]
14:12:34 <ArtB> AB: next, Section 5 - Resolving DOM Nodes
14:12:44 <ArtB> Arve: we don't need to say anything about the URI scheme here
14:13:17 <ArtB> ... I propose removing this section
14:13:33 <Benoit> Benoit has joined #wam
14:13:54 <ArtB> ... and be a bit more specific about how URIs are used where appropriate in the spec
14:14:23 <ArtB> AB: so you propose remove seciton 5?
14:14:25 <ArtB> Arve: yes
14:14:33 <ArtB> AB: any objections to that proposal?
14:14:37 <ArtB> [ None ]
14:14:59 <ArtB> AB: next is 7.3 - identifier attr
14:15:35 <ArtB> ... "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?
14:16:03 <ArtB> Arve: not sure what we should do here
14:16:34 <ArtB> ... my proposal is to use an equivalent element in the config file and to use that
14:16:55 <ArtB> AB: any questions or concerns about that proposal?
14:17:10 <ArtB> ... Marcos, what element would be used?
14:17:14 <ArtB> MC: not sure
14:17:31 <tlr> q+
14:17:51 <ArtB> AB: so the action for  you Arve is to check the config file and come back with a proposal?
14:17:55 <ArtB> Arve: yes
14:18:38 <ArtB> ACTION: Arve create a proposal for the A+E's section 7.3 Red Block issue re the identifier attribute
14:18:38 <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].
14:19:04 <ArtB> TR: is this just needed at runtime?
14:19:22 <ArtB> ... is this put in the base URI
14:19:32 <ArtB> ... want to understand what is needed for
14:19:43 <ArtB> Arve: we do not need to define how it is used
14:20:04 <ArtB> ... at runtime, a unique id is generated
14:20:15 <ArtB> ... and randomizes the base uri
14:20:24 <ArtB> TR: this seems like an imple detail
14:20:37 <ArtB> ... want to understand how it is used by widget instance
14:20:39 <darobin> s/imple/simple/
14:20:44 <Benoit> Benoit has joined #wam
14:20:48 <ArtB> MC: yes, what would a developer use it for?
14:21:13 <Benoit_> Benoit_ has joined #wam
14:21:14 <ArtB> TR: what is this attr used for?
14:21:33 <tlr> it might be that the attribute you really want is origin
14:21:35 <ArtB> ... I don't think I'm getting an answer that substantiates its need
14:21:42 <ArtB> MC: yes, I agree with TLR
14:21:42 <tlr> but that's defined elsewhere ;)
14:21:51 <ArtB> Arve: perhaps you're right
14:22:24 <ArtB> BS: what about cross-widget comm?
14:22:43 <ArtB> MC: not sure we want to include it for that use Benoit
14:22:54 <ArtB> TR: I propose we remove identifier attribute
14:23:09 <ArtB> Arve: if wanted to use post message, could use this
14:23:55 <tlr> sure
14:24:07 <ArtB> AB: let's stop discussion and take this to the mail list
14:24:13 <tlr> AB: raise question in response to Arve's draft on the mailing list
14:24:15 <tlr> TR: sure
14:25:53 <ArtB> Arve: I will submit proposals for all of the Red Block issues starting with the one in Section 7.8
14:25:59 <ArtB> AB: that would be excellent Arve!
14:26:11 <ArtB> Topic: Window Modes spec
14:26:22 <ArtB> AB: what is the status and next steps?
14:26:37 <arve> anyone who wants to derive an origin url, could do so using document.domain
14:26:47 <ArtB> MC: we don't have any new status to report
14:27:04 <ArtB> ... we need an editor
14:27:13 <ArtB> AB: do we have a skeleton doc?
14:27:32 <ArtB> ... I mean anything checked into CVS?
14:27:35 <ArtB> MC: No
14:27:44 <ArtB> AB: any volunteers to drive this?
14:27:49 <tlr> arve, nooo
14:27:55 <ArtB> RB: I will take it!
14:28:13 <ArtB> ... it may be about 10 days though before I can start working on it
14:28:34 <ArtB> AB: excellent Robin!
14:28:38 <Zakim> - +1.919.536.aadd
14:29:04 <fjh> fixes in widget signature complete, apart from latest comments received from Bondi and date of document
14:29:08 <ArtB> AB: any other hot topics
14:29:13 <ArtB> AB: Meeting Adjourned
14:29:21 <Zakim> -fjh
14:29:24 <Zakim> -Art_Barstow
14:29:25 <Zakim> -Mark
14:29:25 <Zakim> - +45.29.aacc
14:29:25 <Zakim> -Thomas
14:29:27 <Zakim> -darobin
14:29:27 <Zakim> -??P2
14:29:30 <ArtB> RRSAgent, make minutes
14:29:30 <RRSAgent> I have made the request to generate http://www.w3.org/2009/03/26-wam-minutes.html ArtB
14:29:39 <Zakim> -arve
14:29:40 <Zakim> IA_WebApps(Widgets)9:00AM has ended
14:29:41 <Zakim> Attendees were fjh, Art_Barstow, Thomas, +1.919.536.aaaa, Mark, darobin, +47.23.69.aabb, arve, [IPcaller], +45.29.aacc, +1.919.536.aadd
14:29:48 <arve> tlr: sorry, a bit imprecise
14:30:06 <tlr> +trout
14:30:15 <Marcos> hhehe
14:30:19 <Marcos> leave poor Zakim alone
14:30:21 <arve> but I think we can ignore identifier until needed
14:30:21 <tlr> zakim, darobin has trout
14:30:21 <Zakim> sorry, tlr, I do not recognize a party named 'darobin'
14:30:45 <tlr> arve, agree on ignoring identifier until needed
14:30:53 <tlr> it won't do us any good now
14:31:27 <Marcos> fjh, do you want met to handle Rainer's comments ?
14:32:16 <ArtB> RRSAgent, bye
14:32:16 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2009/03/26-wam-actions.rdf :
14:32:16 <RRSAgent> ACTION: Arve create a proposal for the A+E's section 7.3 Red Block issue re the identifier attribute [1]
14:32:16 <RRSAgent>   recorded in http://www.w3.org/2009/03/26-wam-irc#T14-18-38