Widgets Voice Conference -- 25 Feb 2010

<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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0707.html ). Given some guests are here today, we will move Announcements to the AOB part of the agenda. Any other change requests?

[ 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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0681.html ).
... to help us all get on the same page here, let's start with Marcos - what's the problem?

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 mandatory
... 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 directionality

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 possible
... 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 = widget.name;

<Zakim> fsasaki, you wanted to provide an example from svg tiny 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 http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup 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,...

<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 return?

<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 string
... 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 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 ealier

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

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 2010-03-04].

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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0595.html ). There was a related follow-up by Henri Sivonen ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0679.html ) and Andreas Kühne again mentioned his company's service ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0596.h

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 agreed

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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0659.html ). What's the status?

MC: I expect Opera will provide some input and I will reflect other comments
... 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 ( 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 window.open
... [ 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 substantial?

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

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 ( http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0170.html ). We discussed this list on Jan 21 ( 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?

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 http://www.w3.org/2010/02/25-wam-minutes.html#action01]

<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

- DRAFT -

Widgets Voice Conference

25 Feb 2010

Attendees

Contents