See also: IRC log
<scribe> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 25 February 2010
<arve> Zakim: calling in?
<arve> Marcos: ^ calling in soon?
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 ]
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
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
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
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
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
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
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
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/you need dir: before span/you need its: before dir or span/ Succeeded: s/http:/-> http:/ Succeeded: s/do we then add an ITS rule/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/ Succeeded: s/need to support the bi-di feature/but most important aspect is to support the bi-di feature, as richard said/ Succeeded: s/MC: don't/AP: don't/ Succeeded: s/look at this?/look at this/ Found ScribeNick: ArtB Found Scribe: Art Default Present: Art_Barstow, arve, fjh, Marcos, aphillip, Richard, [IPcaller], felix, Bryan_Sullivan, Steven Present: Art Arve Frederick Marcos Addison Richard Felix Robin Bryan Regrets: Marcin Agenda: http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0707.html Found Date: 25 Feb 2010 Guessing minutes URL: http://www.w3.org/2010/02/25-wam-minutes.html People with action items: barstow find someone[End of scribe.perl diagnostic output]