GEO Work Scoping
Brainstorm document

This document gathers together brainstormed ideas about how to move forward the work of the GEO (Guidelines, Education & Outreach) task force within the W3C Internationalization Activity.

Note that this is a WORKING DOCUMENT. No implementation intent is implied. No guarrantees are made about the sensibleness, coherence or good structure of ideas. The document is liable to constant change.

Key assumptions

The decision of what should be addressed by the GEO activity, and how it should be addressed, should be driven by practical user needs, rather than by a desire to document what can be said.

GEO will initially focus on development of guidelines, since these will be a required foundation for success in other education and outreach activities.

Implementation approaches

• Create indices to enable people to find specific information quickly - for implementors, make these task based, so the implementor can immediately find specific information AT THE POINT OF NEED - eg. "I'm implementing a table right now, what do I need to take into account for i18n?"
• Create filters to avoid overwhelming people with irrelevant information
• Allow users to access different levels of information according to expertise - experts are likely to just want checklists, novices will need worked examples - novices will become experts in certain areas, and experts will not necessarily know everything, so this has to be fluid, detail should be available on a case by case basis, when required
• For content authors, probably the most useful thing of all would be a tool that gives hints / checks syntax to help them get stuff right - eg. built in to editor, or via an HTML Tidy like tool
  • we should update Tidy to check lang (and xml:lang) attributes, check for encoding declarations, etc.
  • we should also look at the validator tools, and even maybe get checklinks to report the language at the other end of the link (if declared)
• We should internationalise and translate this stuff!
  • we should internationalise our deliverables to showcase ease of localisation
  • translating is likely to throw up internationalisation issues that will need to be worked
  • how should we choose the localised languages? We could just take volunteers, or we could target languages of people who we know need translation to access the material, or who have particular issues, eg. Russians for case 1, Arabic & Hebrew for case 2, ...
• We should have conformance logos, like WAI, and levels of conformance
• We should list browser and standards support of techniques proposed
• We should integrate the material appropriately with that of WAI
  • We may need to allow users to access WAI-only or i18n-only views on the data when needed (eg. for reviews), but we should also not force users to look in two different places for information on how to implement, say, tables when they are trying to find the information at the point of need.
• We need to constantly coordinate with WAI - strategy, knowledge, implementation intent, technical approaches
• We should edit in XML and generate different views of the same data for different purposes - hightens consistency and productivity
• The whole approach to selecting and structuring deliverables should be based on making it maximally effective for a clearly identified group of users - there should be clear signposting for users as to where to find the relevant information for them, right from the Internationalisation Activity home pages down, not just in the documents.
• Localization concerns should be reflected in the guidelines, throughout - not just the need to make things appear correctly on a UA (eg. use/provision of meta information and consideration of approaches needed for effective localisation should be encouraged).
• We should try to establish a database / network of contacts to provide information on specific cultural, linguistic or script questions

Major customer types

• People who are defining new technologies

  These people are likely to need a top down approach to guidelines - ie. starting from the most general rule, work down in granularity, but remain abstract

  • W3C specification developers

  • ML developers

• People who are implementing using existing technologies

  These people are likely to need immediate access to very specific information - the opposite approach to that of reviewers and auditors.

  • Content developers (ie. users of web technology). In fact, this group may eventually need further refinement, eg. page designers, text authors, stylesheet developers, graphic designers, script implementors, etc...

  • Tools developers: editing tools, checking tools, ....

  • User agent developers

  • ISPs

  • Architects

  • Schema developers

  • Administrators (not clear what this is - taken from Workshop conclusions)

• People who are auditing or creating auditing methods

  These people are likely to need a top down approach to guidelines - ie. starting from the most general rule, work down to specific questions related to platform or technology

  • Reviewers and auditors of specifications, documents, and web user interfaces

• Localisers

  • We need to figure out what their requirements are, and encourage agreement and standardisation by the localisation industry

• Managers

Technical topic areas

• Existing techologies
  • XML
  • HTML
  • CSS
  • XSLT & XSL:FO
  • XForms
  • XML Schema
  • XQuery, XPointer, etc.
  • etc.
• Architectural approach (likely to draw on CharMod)
• Script-integrated web application development
  • Using JSP, ASP, Perl, etc. to serve data
  • XML & Java, XML & Perl, etc.
  • Dynamic HMTL with ECMAScript, VB, DOM, etc.
• Server setup, directory structures, etc.
• Localisation interfaces

Richard Ishida ([email protected])
$Id: geo-scoping.html,v 1.3 2003/04/14 12:10:34 rishida Exp $