[widgets] Draft minutes from 25 February 2010 voice conf

The draft minutes from the February 25 Widgets voice conference are  
available at the following and copied below:


WG Members - if you have any comments, corrections, etc., please send  
them to the public-webapps mail list before March 4 (the next Widgets  
voice conference); otherwise these minutes will be considered Approved.

-Regards, Art Barstow


       [1] http://www.w3.org/

                                - DRAFT -

                        Widgets Voice Conference

25 Feb 2010


       [2] http://lists.w3.org/Archives/Public/public-webapps/ 

    See also: [3]IRC log

       [3] http://www.w3.org/2010/02/25-wam-irc


           Art, Arve, Frederick, Marcos, Addison, Richard, Felix, Robin,





      * [4]Topics
          1. [5]Review and tweak agenda
          2. [6]P&C spec: ITS
          3. [7]DigSig spec: C14N
          4. [8]Interface spec: openURL security considerations
          5. [9]Interface spec: resolution of relative URIs
          6. [10]View Modes Media Feature spec: LC ToDo list
          7. [11]AOB & Announcements
      * [12]Summary of Action Items

    <scribe> ScribeNick: ArtB

    <scribe> Scribe: Art

    Date: 25 February 2010

    <arve> Zakim: calling in?

    <arve> Marcos: ^ calling in soon?

Review and tweak agenda

    AB: the agenda was posted on Feb 24 (
    07.html ). Given some guests are here today, we will move
    Announcements to the AOB part of the agenda. Any other change

      [13] http://lists.w3.org/Archives/Public/public-webapps/ 

    [ none ]

P&C spec: ITS

    AB: an issue with the P&C spec is what to do about the Optional ITS
    support. On February 22 Marcos sent a proposal to WebApps and I18N
    Core WG (
    81.html ).
    ... to help us all get on the same page here, let's start with
    Marcos - what's the problem?

      [14] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: the config doc permits pieces of metadata
    ... some of that metadata could be marked up with ITS elements
    ... not sure what the UA is supposed to do
    ... We have one partial impl of ITS
    ... so we are concerned about how to move the spec forward

    RI: there are a couple of things here
    ... one issue is bi-di support
    ... the other has to do with how the markup is used

    MC: yes, I agree

    <darobin> +1

    MC: we don't want to remove the capability

    RI: then we should talk about bi-di support versus ITS support
    ... do you now have a dir tag without an its prefix?

    MC: there is some confusion about the syntax
    ... we don't define dir in the widget ns
    ... some confusion from the author's point of view

    RI: from our PoV, very imp to support bi-di
    ... but dont think you need its: before dir or span
    ... spec says you can use your own tag

    MC: that's what we want
    ... don't want to add another namespace

    AP: that's OK with us
    ... there are lots of grammars that have span elements and dir attrs
    ... import the functionailty into your own spec

    <fsasaki> felix: agree with what Richard said


    FS: want to second what RI and AP said
    ... follow the above link
    ... to see an example you could follow

    RB: so if we add span and dir to our namespace
    ... do we then add an ITS rule to that specification so that it can
    be plugged into ITS-supporting software easily and capture the
    intent clearly?

    FS: I think it would be useful
    ... but most important aspect is to support the bi-di feature, as
    richard said

    RI: let me summarize
    ... ITS spec: tells the set of features needed including bidi; gives
    advice for translators; provides a mech one can follow to define the
    tags needed
    ... and Felix's example illustrates that

    <Marcos> +q

    MC: hearing good use cases
    ... would be good to expand on how to use ITS functions
    ... think we should put that in a separate spec

    AP: I'm a little hesitant to separate it
    ... by splitting, it tends to invite people not to implement it

    RI: yes, I tend to agree
    ... something like bi-di really needs to be there

    MC: so if we introduce span and dir, then we would need to make it
    ... currently, it is optional

    <Steven> Is there a link to the place where it says ITS is optional?

    AP: providing proper bidi markup is very importatnt
    ... the way you implement it is up to you
    ... it is key to have the right syntax
    ... and provide enuf info for implementors

    <Zakim> darobin, you wanted to ask about unicode-based

    RB: 3 small things ...
    ... I think there is a strong consensus to support bidi
    ... but we have lots of pressure to release the spec now
    ... we have made promises to proceed from CR to REC as soon as
    ... I have a question about how to express the value of bidi markup
    versus using unicode markers for directionality
    ... Unicode chars can be used so not clear we need anything else
    ... 3rd, re API, we return a string that may contain the span
    element. How is that handled?

    RI: we are discussion bidi in the context of HTML
    ... they are pushing for markup rather than the Unicode chars
    ... authors can't see them
    ... very difficult with paragraph endings
    ... also inheritance probs
    ... so markup is cleaner

    AP: RI hit the main points
    ... dir attr does have a certain amount of scope
    ... if have structure element, can set base directionality
    ... [ missed stuff about blocks of stuf ... ]
    ... e.g. can say widget name is LtoR or RtoL
    ... The unicode markers are more relevant for paragraphs

    <r12a> actually unicode markers are only inline indicators

    AP: adding markers for LtoR langs can be a pain for authors

    <r12a> (which makes for much more work on the authors part to
    support them too)

    RB: so markup is better for authoring

    <darobin> ... and structure

    RI: inheritance is also important
    ... if writing a config file, want to put dir at the top and then
    not have to do it again
    ... if use markers, it's a lot more work for the author
    ... inheritance via markup is much more workable for authors

    <Marcos> +q

    <darobin> API example: <name>Foo <span dir='rtl'>esrever</span>
    Bar</name> when that value is retrieved with var nameString =

    <Zakim> fsasaki, you wanted to provide an example from svg tiny

      [15] http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup

    MC: question about this when xml:lang is used
    ... does the lang give a hint about dir?

    AP: xml:lang can be a hint about what content will follow
    ... but it does not define directionality
    ... we discouage using xml:lang as an indicator for directionality
    ... we have some examples

    RI: the function of lang and dir are fundamentally different

    MC: ok, thanks for clarifying

    <fsasaki> felix: the svg tiny example
    demonstrates how ITS markup is integrated into a language (SVG)
    *without changing the behavior of svg* - but the markup is still
    important for applications which process svg, e.g. translation
    tools. So adding the markup does not mean IMO that you need to go
    back in the w3c process. Also, regarding "re API,...

      [16] http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup

    <fsasaki> ...we return a string that may contain the span element.
    How is that handled?": not sure if there is a need to keep the span
    element in the DOM, since it is not relevant for widget processing.

    FS: I just entered what I wanted to say
    ... don't think the P&C spec should need to define how to process
    text bidi marked text

    RB: it's not so much about the DOM

    <darobin> <name>Foo <span dir='rtl'>esrever</span> Bar</name> when
    that value is retrieved with var nameString = widget.name;

    RB: the algorithm ignores stuff it doesn't understand
    ... re the example I entered above, not sure how to expose the
    string so it can be displayed properly later on
    ... don't want the info to be lost

    AP: the API would need to preserve directionality

    RB: so if the API returns a human readable string, what do we

    <fsasaki> felix: agree with directionality - only no need to
    preserver any other ITS information derived from the markup (e.g.
    the "translate" flag)

    RI: if using JS, then could use markers
    ... and then do the conversions

    AP: would expect name element to have the dir attr
    ... can then have an api to get the dir

    MC: do we insert the unicode control points or not?

    <darobin> RB: the issue is indeed for JS APIs, for instance for the
    generation of About boxes — the JS does not have access to the
    original XML, just the API on top of it

    AP: if you have other markup, then want to turn the markup to a
    ... need to be careful; don't want to loose info
    ... and don't want the API to be too difficult
    ... need to work thru the main use cases
    ... to determine what soln to use

    MC: our case is mainly human readable text

    AP: may need a separate API to get directionality

    <darobin> ACTION Robin to produce examples of API retrieval of
    human-readable text with directional information

    <trackbot> Created ACTION-495 - Produce examples of API retrieval of
    human-readable text with directional information [on Robin Berjon -
    due 2010-03-04].

    <arve> WTF?

    AP: don't want to loose directionality of the span

    RB: I'll need to look into this API problem
    ... I will then send it to you for review
    ... if that sounds OK

    RI: sound good

    AP: yes

    MC: I'll help with the examples

    <Marcos> proposal [17]http://dev.w3.org/2006/waf/widgets-bidi/

      [17] http://dev.w3.org/2006/waf/widgets-bidi/

    AB: what is this Marcos?

    MC: it's a separate spec for widget directionality
    ... need to clearly define what needs to be done with bidi
    ... already think this proposal needs to have some changes based on
    today's discussion
    ... Based on the examples, will be able to update the API

    RI: may have a similar issue with lang
    ... it can be on spans, and other places

    MC: yes, we need to look at the various cases

    RI: there are no unicode markers for lang

    AB: so if we were to move the ITS functionality to a separate spec,
    would that be objectionably?

    AP: yes, I think the I18N Core WG would find that objectionable
    ... concerns about it not getting implemented and others I mentioned

    MC: yes, understand; we have very little support for it now from

    RB: it is much easier for us to tell people to implement a small
    separate spec then it is to implement an Optional part of a spec

    AP: the attributes are not optional
    ... the effect they have is sometimes not optional
    ... there is a right thing to do

    MC: we could do this in a seperate spec and in P&C spec, say this
    the Widget BiDi spec SHOULD/MUST be implemented
    ... want to finish P&C
    ... we have a good test suite and we can add some ITS tests
    ... I think that would address the concerns you expressed
    ... then we can add additonal use cases as needed

    RI: if put span and dir in the grammar in P&C and then specify them
    in a separate spec

    MC: yes, we can do that

    RI: are you saying that in the P&C spec, define the span and dir as
    mandatory and then specing them separately?

    MC: yes

    RB: I think that would be OK

    RI: I think we would say that isn't the preferred plan

    RB: I agree it's not our preferred plan either but we need to ship
    the spec

    <Steven> Which argues against a three week LC by the way

    <fsasaki> felix: agree with that plan - not preferred, but still ok

    AP: will be painful if you take it away and then try to add it later

    AB: then this plan wouldn't be ideal but would meet the I Can Live
    With It Test

    RI: the examples we've seen today aren't real convincing and I can
    supply others

    RB: that would be great

    <darobin> ACTION Marcos to email I18N to ask for better examples,
    edit P+C to match decision

    <trackbot> Created ACTION-496 - Email I18N to ask for better
    examples, edit P+C to match decision [on Marcos Caceres - due

    SP: wasn't clear on the Core feedback loop

    RB: we got some feedback to use markers
    ... but we we want to keep moving the spec forward

    <darobin> .... we should have done the i18n tests first

DigSig spec: C14N

    AB: on Feb 12, Marcos started a thread related to the Canonical XML
    spec (
    95.html ). There was a related follow-up by Henri Sivonen (
    79.html ) and Andreas Kühne again mentioned his company's service (

      [18] http://lists.w3.org/Archives/Public/public-webapps/ 
      [19] http://lists.w3.org/Archives/Public/public-webapps/ 
      [20] http://lists.w3.org/Archives/Public/public-webapps/ 


    ml ).

    AB: I don't think any new information has been added to the
    discussion about using using XML Signature for widget signing.
    ... do we have an issue to discuss?

    <fjh> I saw nothing new in the discussion

    MC: no I don't think so
    ... I talked to our guys but we are OK with proceeding as already

    AB: proposed resolution: we continue as previously agreed with Dig
    Sig spec
    ... any objections?

    [ None ]

    RESOLUTION: we will continue as previously agreed with Dig Sig spec

Interface spec: openURL security considerations

    AB: on Feb 18, Marcos asked for input on openURL security
    considerations (
    59.html ). What's the status?

      [21] http://lists.w3.org/Archives/Public/public-webapps/ 

    MC: I expect Opera will provide some input and I will reflect other
    ... there are some issues with this method so we need to be cautious

    AB: will addressing the issue require normative changes to the spec?

    MC: no, I don't think so
    ... we need to provide some more guidance for implementors

    AB: I think we're OK here

    MC: yes, I'll refine the informative text

Interface spec: resolution of relative URIs

    AB: on Feb 24, Arve asked a question in IRC re how relative URIs are
    resolved ( [22]http://krijnhoetmer.nl/irc-logs/webapps/20100223 ).

      [22] http://krijnhoetmer.nl/irc-logs/webapps/20100223

    Arve: the spec has some text about relative URIs
    ... may have a conflict between openURL and similar APIs like
    ... [ Arve make a proposal that is not minuted ... ]
    ... must look at the resolved URI and not the string

    MC: yes, that makes sense; I can work with Arve on this
    ... that change would simplify some things as well

    AB: is this going to be editorial change or something more

    MC: I think this is more of an editorial change
    ... but after I am done editing we can decide if the change is more

    Arve: I agre this is more editorial

View Modes Media Feature spec: LC ToDo list

    AB: on Jan 14, Marcin posted a list of 4 open issues for the VMMF
    spec (
    70.html ). We discussed this list on Jan 21 (
    [24]http://www.w3.org/2010/01/21-wam-minutes.html#item06 ).
    ... Since then were no follow-ups, want to go thru the list and get
    an understanding about what needs to be done to address the issues.
    ... note for the record that Marcin sent regrets for today
    ... what is the priority of this spec?

      [23] http://lists.w3.org/Archives/Public/public-webapps/ 
      [24] http://www.w3.org/2010/01/21-wam-minutes.html#item06

    RB: I can take a look at this

    <darobin> ... it's a question of what the WG's priorities are

    <Marcos> darobin to view modes!

    AB: if this spec is getting implemented, we need to freeze it

    MC: we need someone to take editorial control
    ... my priority is Update spec at the moment

    <scribe> ACTION: barstow find someone to help drive the View Modes
    Media Feature spec to LC [recorded in

    <trackbot> Created ACTION-497 - Find someone to help drive the View
    Modes Media Feature spec to LC [on Arthur Barstow - due 2010-03-04].

    Arve: I can look inside

    AB: I'll do the same

    <darobin> RobinCopter

AOB & Announcements

    AB: any short announcements for today?

    RB: I sent the URI scheme registration request

    AB: yes, saw that; thanks!
    ... next call is March 4; no call on March 11; meeting adjourned

    <darobin> we should have a Mr Barstow song

Summary of Action Items

    [NEW] ACTION: barstow find someone to help drive the View Modes
    Media Feature spec to LC [recorded in

    [End of minutes]

Received on Thursday, 25 February 2010 15:29:16 UTC