Minutes 2005-03-23: GEO telecon

Minutes 2005-03-23: GEO telecon, at at 17:00 UTC/GMT, 10:00 Seattle, 13:00 Boston, 18:00 London, 19:00 Paris, 03:00 Melbourne



ATTENDEES 

Deborah Cawkwell (BBC, Scribe) 
Richard Ishida (W3C, Chair) 
Susan Miller (Boeing) 



NEW ACTIONS 

DC, FAQ: what to consider when upgrading to Uncode? Add comments to WIKI. 
DC, check CSS spec to double-check wording ('generic font family'). 
DC, question to IG list: Why utf-8 rather than utf-16? 
RI, Talk to JY re Global Gateway 
SM, Getting started - circulate draft by 30 March 
DC, Discount usability: set up WIKI page with user profiles & task scenarios drawing from discussions at FTF meeting 
RI, in WIKI instructions (top) to add specifically "DON'T WORD SMITH" at early-draft stage 



REVIEW OF GEO WORK ITEMS 

RI, Update plan/pipeline document with different structure. - DONE 
All, Read FTF minutes - Done by folks on the call 
RI, Talk to JY re Global Gateway - Outstanding 
DC, Unicode upgrade - circulate before next meeting - DONE 
SM, Getting started - circulate draft by 30 March - ongoing 
DC, Discount usability: set up WIKI page with user profiles & task scenarios drawing from discussions at FTF meeting - pending

SM, Feedback at bottom of FAQ, eg, "Do you have a topic for an FAQ?" (analogy with news stories). User more likely to engage with it on a FAQ representing information they have actively sought. Elaborate in email to list - DONE

DC, Vote widget on FAQ page: "How useful did you find this page?" or "Did this FAQ answer your question?" Elaborate in email to list - DONE



INFO SHARE 

DC: meta content-lang added to majority of BBC WS sites, eg, http://www.bbc.co.uk/hindi 

RU: tutorial development 
- bug fixing / programming related to slide presentation 
- writing for www conference for tutorial track 
- uploaded one for bi-di http://www.w3.org/International/tutorials/bidi-xhtml/

- welcomes comments 
- uploaded, but not yet 'live' as terms of 'linked to'/publicised 
- security by obsurity 

RI: work on lang declarations 
- related tutorial on this subject exists already in GEO 
- covers some of the ground 
- new stuff separate  
- focussed on declaring language 
- then when finished this would be separate & removed from existing tutorial 

RI: other tutorials planned: 
- CSS use for Far Eastern languages using CSS3 in particular 
- Ruby styling 
- IDN & IRI  

RI: presentation work on tutorial RI has given at Unicode conference for about 10 years 
- putting into slide form 
- characteristics of non-Latin language systems 
- will be announced by email as 1st draft available 

RI: material for www conference handout - required by 31 march 

Felix Sasaki, new W3C team member (taking over part of MD's role) in Japan at the moment 
- will return to Germany at the end of the week 
- will attend Unicode conference in Berlin in April 
- will be active from the end of April to the beginning of May 
- MD leaves at the end of next week 



DISCUSSIONS 

Use of Zakim queue 

Type "+q" and optionally the comment/question. 



FAQ / Articles feedback generally 
- word-smithing too soon, rather than focussing on what we really want to say 
- WIKI is more effective where comments & responses are together - much less productive if had to look through different emails 

- process 
1) scope 
2) active research / questions to list 
2) answers, explanations 
3) word-smithing 

RI: in WIKI instructions (top) to add specifically "DON'T WORD SMITH" at early-draft stage 



FAQ: What to consider when upgrading to Unicode? - DC 

ACTION DC, add comments to WIKI 
- Add "answer" to conform with standard style 
- What should "I" rather than "you" consider when upgrading.... 
- Scope not clear, change question to "you've taken the decision to upgrade to Unicode, what issues do I need to address?" - in the case of the question, word-smithing is ALWAYS appropriate as it sets the direction for the FAQ.

- Most important question doesn't appear at all: 'how widely is Unicode supported for my users?', 'will my users be able to see the stuff?'. Addressed under rendering, but that wording/approach not useful. Depends on:

1) browser support? 
2) fonts? 
3) rendering software? 
- Expect structure to be more in terms of pros & cons plus 'how to', "what's the ISSUE, what's the suggested resolution?".

- State issue first, then solution. View in terms of people skimming, front-load most important information, "what do I need to do here", "what's the problem?". If people know, they can skip to the next section.

- 'Suitable font' too vague 
- More detail: all of these browsers & list 
- "All modern browsers" pretty much correct but vague 
- Specify which browser versions in significant families 
- OS font vs UA distinction not clear enough, currently implies that if font isn't visible, UA doesn't support Unicode, which is wrong, probably that you need a font to display those characters on your system 

- Clarify: don't need huge Unicode font - user would need a font which would display appropriate necessary Unicode characters, cf, OS / UA combinations.

- Ensure users have fonts, which probably will have as built into system. 
- Usually Unicode fonts cover 'specific' scripts, point to Alan Wood's v useful list of Unicode fonts & and to http://www.babelstone.co.uk/Fonts/Fonts.html.

- CSS generic font family fallbacks very relevant, eg, serif, sans-serif: always good practice. DC ACTION check CSS spec to double-check wording ('generic font family'). 

- Para begining "ISO...", easier to say this: 
1) issue people might see rectangles, if they don't have correct fonts. This is only the case if multi-lingual text. In the current draft sounds like a general unicode problem 

- Multi-lingual text rendering engines: don't seem very useful as a list like this: maybe as part of section sugggested above?

- Mobile phone support should be with 'will my user see the stuff?' section. 
- Character encoding declaration: rather you need to ensure that you change the way you serve your files, so the information is up-to-date.

- 'Consider' a section: "things you don't have to think about", eg heaviness 
- Which unicode encoding? ACTION DC: question to IG list: Why utf-8 rather than utf-16? Possibly better compatibility with legacy data, ie ASCII / UTF-8.. 

- Don't mention BMP. (BMP = first 65k approx characters, then introduced 15/16 more planes of characters, all have 65k characters in them, most of more common scripts in first BMP. 1 byte stuff: only 7-bit ASCII, not upper ASCII, ie ANSI, ANSI territory -> 2 bytes, 2 bytes beg/end Arabic, 3 bytes ideographic characters Chinese & Japanese - it's the script which is important here.  

- UTF-8 uses 1 byte to represent characters in the old ASCII set, two bytes for characters in several more alphabetic blocks, and three bytes for the rest of the BMP. Supplementary characters use 4 bytes.

- UTF-16 uses 2 bytes for any character in the BMP, and 4 bytes for supplementary characters. 
- UTF-32 uses 4 bytes everywhere. In the chart above, the first line of numbers represents the position of the characters in the Unicode coded character set. The other lines show the byte values used to represent that character in a particular character encoding.



http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system. 
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received. 
Further communication will signify your consent to this.

Received on Wednesday, 30 March 2005 14:13:56 UTC