The draft minutes from the February 25 Widgets voice conference are
available at the following and copied below:
http://www.w3.org/2010/02/25-wam-minutes.html
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]W3C
[1] http://www.w3.org/
- DRAFT -
Widgets Voice Conference
25 Feb 2010
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0707.html
See also: [3]IRC log
[3] http://www.w3.org/2010/02/25-wam-irc
Attendees
Present
Art, Arve, Frederick, Marcos, Addison, Richard, Felix, Robin,
Bryan
Regrets
Marcin
Chair
Art
Scribe
Art
Contents
* [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 (
[13]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/07
07.html ). Given some guests are here today, we will move
Announcements to the AOB part of the agenda. Any other change
requests?
[13] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0707.html
[ 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 (
[14]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/06
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/
2010JanMar/0681.html
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
<fsasaki>
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
[15]http://www.w3.org/TR/SVGTiny12/i18n.html#SVGi18nl10nmarkup
[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
[16]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,...
[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
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 [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
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 (
[18]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05
95.html ). There was a related follow-up by Henri Sivonen (
[19]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/06
79.html ) and Andreas Kühne again mentioned his company's service (
[20]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/05
96.h
[18] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0595.html
[19] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0679.html
[20] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0596.h
t
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 (
[21]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/06
59.html ). What's the status?
[21] http://lists.w3.org/Archives/Public/public-webapps/
2010JanMar/0659.html
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 ( [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
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 (
[23]http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/01
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/
2010JanMar/0170.html
[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
[25]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
Summary of Action Items
[NEW] ACTION: barstow find someone to help drive the View Modes
Media Feature spec to LC [recorded in
[26]http://www.w3.org/2010/02/25-wam-minutes.html#action01]
[End of minutes]
