Minutes 2005-04-05: ITS face-to-face meeting from Yves Savourel on 2005-04-11 (public-i18n-its@w3.org from April to June 2005)

From: Yves Savourel <ysavourel@translate.com>
Date: Mon, 11 Apr 2005 09:50:17 -0600
To: <public-i18n-its@w3.org>
Message-ID: <HYDRA1vmpJEqZXoXmBo0000060e@hydra.RWS.LOCAL>
Minutes 2005-04-05: ITS face-to-face meeting

ATTENDEES:

- RI: Richard Ishida (W3C)
- FS: Felix Sasaki (W3C)
- CL: Christian Lieske (SAP)
- AZ: Andrzej Zydron (Invited Expert)
- YS: Yves Savourel (ENLASO)

JOINED TELECONFERENCE:

- DS: Diane Stoick (Boeing)
- NN: Naoyuki Nomura (Ricoh)

REGRETS FOR TELECONFERENCE:

- MI: Masaki Itagaki (Invited Expert)
- TF: Tim Foster (Sun)

AGENDA:

http://www.w3.org/International/its/ftf-200504-Berlin.html#Objective


=== INTRODUCTION

Everybody introduced himself.
We quickly discussed the agenda.


=== SCHEMAS

FS provided the group with a presentation on schema languages.
The latest version of the slides (updated after the meeting) can be found here:
http://lists.w3.org/Archives/Member/member-i18n-its/2005AprJun/0003.html

We agreed to use consistently specific terms:
- "schema" means DTD, XML Schema, Schematron, etc. (i.e. any schema language)
- "XML Schema" means XML Schema.
RI question: Will we need to choose our target for ITS: XML Schema, Relax NG, DTD, etc. 
Maybe some could be a generic description + normative "example".
CL: thinks it's important to start to gather collection of examples.
RI: X/HTML is one good example. FS: There are Relax NG schema and XML Schema schema for XHTML.
RI: make sure we note down things to say to localization tools providers.
We then had some discussion about entities and dependencies to schema.
RI: In XHTML-2 the recommendation is to drop the Latin-1 character entities, but keep the entities for ambiguous characters such as
non-breaking space, zero-joiner, etc.


=== DIRECTIVES VS. PROPERTIES VS, TAG SET

Note that this discussion touches on implementation ideas, not just requirements.

We discussed at length the different terms "localization directives", "localization properties", and "(internationalization) tag
set". We agreed that we needed a short definition of those terms in the Requirements documents.

"localization properties": a set of data, external to the documents that provide tools with i18n/l10n information for a given
document type. The tag set should help the tools to generate such set of properties.

"localization directives": in general (not just for XML), information inside the material to localize that provide the
tools/localizers for information that either complement or override the localization properties. In XML, this would be offer through
the internationalization tag set.

"internationalization tag set": in XML, a specialized vocabulary that provide i18n/l10n information at different levels. We
identified several usages for the tag set in XML:

1- in schemas
	1.1- to assign a l10n/i18n info to the defined element/attribute
	1.2- for "normal" use (e.g. to translate documentation within the schema document)
2- in documents instances
	2.1- grouped in a single location (e.g. top of the file)
	2.2- within elements (where the information applies)

Users: the schema writer, the content author, the localizer.
The following example illustrate 1.1, 2.1, and 2.2. (these are just examples and do reflect a preferred syntax).

--- start example ---
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:its="httt"
 elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:element name="root">
  <xs:complexType>
   <xs:attribute name="its:translate" type="xs:anySimpleType" default="no"/>
  </xs:complexType>
 </xs:element>
</xs:schema>
--- end example ---

--- start example ---
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns:its="httt" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\Documents and
Settings\d025418\My Documents\Untitled1.xsd" its:locPCDATA="yes" its:doNotTranslate="a,b, xpath"
<header>
<its:feature value="yes" location="\a\b|\c">translate</its:feature>
</header>
<body>
<para>Some text <a its:translate="yes">other text</a> text</para>
<div><para>Some text</para>
<para>Some text</para>
<para>Some text</para>
</div>
</body>
</root>
--- end example ---

AZ listed the main information needed for properties:
- inline elements
- transltable/non-translatable values and content
- places where whitespaces should be preserved
For document-type documents PCDATA is usually translatable by default.

CL noted that the tag set data cat, where you use it anywhere you want.
FS noted that RDF could be one way to help in implementing such information.
CL gave an example of usage at the top of the document and within the document, similar to the use of CSS information. Such CSS-like
mechanism would work the same way in all types of location (instance, schemas, etc.)
FS mentioned that we may need different solutions depending on the schema language.

RI listed the different usages possible:
- tag set
- style sheet
- meta info (HLink (simplified XLink): at the top of file), (meta properties (XHTML2 for example), RDF.

FS: we could use RDF to bring different realizations together (so mapped to any of above)
CL noted that sometimes we cannot modify the schemas.
CL showed examples of such ITS css-like.
RI: We will come back to such thing when doing bidi. We will need markup to delimit parts of text.

CL noted that sometimes information in the schema would not be enough because the same schema may be used in different context. For
example: One user would want <designnote> to be translatable, while the other would not.
AZ: Then you can use the properties to tune it up per case.

CL: We will need to define mechanism for feature proliferation (inheritance, trickle down, etc.)
RI: Cascading.
CL summarized: we need to work from two angles:
- the features 
- the feature location(s)



=== REQUIREMENT DOCUMENT STRUCTURE

We discussed the general structure needed for the Requirements document, and came up with the following:

1. Introduction
	1.1. Background	
	1.2. Who should Read This?
	1.3. Overview
	1.4. Key Definitions (directives etc. short, reference to main definitions if any exist)
2. Usage Scenarios
	2.1. From the schema author viewpoint
	2.2. From the content author viewpoint
	2.3. From the localization engineer viewpoint
	2.4. From the tool provider viewpoint (e.g. generate loc. properties from XSD)
	2.5. others...
3. Requirements
	3.1. First requirement
	3.2. etc...

For usage scenarios (=use cases) we felt that it would be important to have examples from the different users viewpoints. We could
also classify the different scenarios by type of users.

We discussed the main sections in the requirements drafts, and came up with this:
RNNN (we will number the requirements)
- Summary - A method must exist... (maybe be easier to write last)
- Issue - Why do we need a method? What is the problem?
	Example 1
	Example 2
- Description - Long version of summary
- Quick Guideline Thoughts (may or may not end up in the final requirement)
- Notes - e.g. comments on particular implementations, relevant links etc.

RI explained that the idea is to do "front loading": putting the more important content first.



=== REQUIREMENTS

RI summarized the usage of the wiki to create and maintain work items like the draft requirements items.
The EWS wiki now allows us to edit the pages while other can only read them.
RI added a system for notifying the public mailing list each time a page is updated.
RI to post a summary of instruction on how ITS is to use the wiki.
YS to update the web site to provide quick access to the wiki parts.

CL asked if we needed to have a requirement for a mechanism for mapping existing tag to ITS.
AZ mentioned DITA. He will post a summary.

RI reminded everyone that we need to use the public list for all technical emails, make sure to have separate threads for different
topics, and when replying to an email, use the same thread. It makes things much more easy to follow.



=== TELECONFERENCE:

DS and NN called in for the teleconference at 16:00.
YS summarized the things done during the day.
Then we went online and put a final touch using the wiki to the "Entities handling" requirements.
http://esw.w3.org/topic/its0503ReqEntities



=== OTHER BUSINESS

- Next meeting is Apr-14 at 14:00 UTC (information will be posted as usual).
RI asked if the summer time could maybe allow us other meetings more easy for Japan.
YS to check the different combinations.



=== ACTION ITEMS

- RI to post a summary of instruction on how we are going to use the wiki.

- YS to update the ITS pages to provide quick access to the wiki pages.

- YS to check the different time combinations for possible better teleconference time.

- All (who have not done it yet): go to one of the Wiki page (e.g. http://esw.w3.org/topic/its0503ReqEntities) and register as a
user. Then send the user name to Richard so he can add you to the security user list.


Cheers,
-yves
Received on Monday, 11 April 2005 15:50:33 UTC