I18N ITS f2f -- 20 Sep 2005

Sebastian's Example of Using ODD for ITS WG purposes

Felix: Is the URI of the equiv element a namespace URI?

Sebastian: No, it's a URL - actually the specification for the equiv element is somewhat underspecified
... The ODD instance has embedded description and examples
... The ODD instance also features a somewhat complex type (see 'translate()')

<felixSophia> http://users.ox.ac.uk/~rahtz/its/its.doc.html

Sebastian: The HTML rendering looks as above
... The HTML rendering can be done for other languages (see URL below)

<r12a-sophia> http://users.ox.ac.uk/~rahtz/its/its.rnc

Felix: Japanese is styled somewhat strange (since Japanese does not work with italics)

<r12a-sophia> http://users.ox.ac.uk/~rahtz/its/its.xsd

<r12a-sophia> http://users.ox.ac.uk/~rahtz/its/its.dtd

Sebastian: The schemas which can be generated from the ODD example look as above
... RelaxNG and DTD are generated by means of XSLT
... XSD is generated with James Clark's TRANG

Sebastian (SR): I will now show you what a declaration for ITS purposes which complies to the format we described in the ODD instance would look like in an XML instance

SR: The example is different from yesterday's example since it uses a function-like notation 'translate()' rather than the CSS-like notation 'translate:yes'
... translate(0.5) could be defined as being equal to 'translate:maybe'
... The format we described in the ODD instance would also allow that 'translate()' could be used for direct marking
... Example for direct marking: <p its:localize="translate(1)">...</p>
... An ODD instance can also be rendered as PDF

<felixSophia> CL: a remark

<felixSophia> .. how to relate the annotation and documentation in an xsd to language specific versions?

<felixSophia> YS: Documentation is one thing

<felixSophia> .. but generating all from one thing is pretty nice

<felixSophia> CL: This "literate programming" style is really useful

<felixSophia> translation of documentation into french: http://www.tei-c.org/I18N/person-fr-sr.xml

<SebastianR> <Declarations xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

<SebastianR> xsi:schemaLocation="http://w3c.org/ns/its its.xsd"

<SebastianR> xmlns:its="http://w3c.org/ns/its"

<SebastianR> xmlns="http://w3c.org/ns/its">

<SebastianR> <Name>Christian</Name>

SR: The above is the XML instance (using the ITS defined) mentioned above
... The example implementation would not give you ITS-specific types in the PSVI
... We have not demoed how to include for example the XSD into the host schema
... The inclusion might be easy or difficult (depending on the host schema)

<felixSophia> link to context specification with the namespace routing language: http://www.thaiopensource.com/relaxng/nrl.html#Element-name_context

FS: With NRL, processing of an ITS included in a host schema might be easy

YS: What is the status of ODD?

SR: ODD is a module of TEI. It's the language in which TEI is written

<SebastianR> http://www.tei-c.org/P5/

YS: Is ODD something we could use for editing our ITS WG work

SR: The examples above showed that we could do this
... A shortcoming I stumbled across: I could not figure out how to define a namespace for an attribute

<felixSophia> CL: two questions on the examples from SR

<felixSophia> .. how do we write the specification?

<felixSophia> .. I think we could use odd to do this

<felixSophia> .. using trang, interleaving with xhtml, would be an alternative

<felixSophia> .. should we make a decision on using odd or not?

<SebastianR> schemas:

<SebastianR> xsltproc --stringparam outputDir . \

<SebastianR> /usr/share/xml/tei/stylesheet/odds/odd2dtd.xsl its.odd

<SebastianR> xsltproc --stringparam RNGDIR . \

<SebastianR> /usr/share/xml/tei/stylesheet/odds/odd2relax.xsl its.odd

<SebastianR> that was the script I used to take a .odd file and generate schemas.

FS: I propose that we first test this. We could assign action items related to testing
... It seems reasonable that the editors take the action items
... Who will be the editors?

<SebastianR> http://www.tei-c.org.uk/release/xml/tei/custom/schema/relaxng/p5odds.rnc

CL: I could co-edit as long as co-editing time does not exceed the time I am allowed to spend on ITS

<SebastianR> that was the schema for ODD

FS: So I suggest that I myself start with Ruby and CL starts with indicator of translatability

<felixSophia> CL: SR refined the abstract language we discussed yesterday

<felixSophia> .. I wonder when we will discuss the refinement

<felixSophia> YS: we will discuss that as topic 2 and 3 today

<scribe> ACTION: FS to use ODD to specify Ruby requirements [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action01]

<felixSophia> http://www.w3.org/International/its/possible-implementations/transPlusRuby.html

<scribe> ACTION: CL to use ODD to specify indicator of translatability requirements [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action02]

<scribe> ACTION: SR to help FS and CL to set up ODD processing environment [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action03]

Felix' Example of Specifying the Indicator of Translatability wrt. the Implementation Choices we Discussed

FS: The URL above takes you to the example
... The examples will clarify the general conventions (e.g. attaching info to the first child)

SR: Question related to solution for task 1
... Is xs:appinfo meant to be used that way?

FS: Yes, it's for processors which does things different from validation

RI: Question related to solution for task 2
... The convention 'its:info always first child' does not seem advantegous

FS: On second thought, the convention really does not seem good. I will reconsider
... Example 1 and 3 are quite similar (difference: in example 1, ITS stuff is attached to the root element)

YS: Question related to solution for task 3
... How could we for example make context-specific definitions (e.g. say something about a paragraph in a footnote)

FS: It really depends on the schema dialect

RI: General question
... Shouldn't we carefully discuss scoping? I remember e.g. observations related to xml:lang along the lines of 'inheritance was not obvious'

SR: Question related to solution for task 5
... Can't we attach xs:appinfo to xs:attribute?

FS: You can do this, however, I did not do this.
... My approach realized a homogenoues handling in schemas _and_ instances

SR: The approach, however, does not work well for globally defined attributes or attribute groups (ie. attributes picked up from outside of the element declaration)

FS: Remark on solution for task 7
... The extension could for example take the CSS-like notation we discussed yesterday

<YvesS> CL: two high level comments

<felixSophia> CL: commments

<felixSophia> .. the examples contribute to what we want to achieve

<YvesS> ..this type of examples are needed in our deliverables

<felixSophia> .. but we should look into the specific conventions felix described

<felixSophia> .. having an its:info container is also to be discussed

<felixSophia> .. also, we need to show how to do this with a DTD

<felixSophia> .. as for the general conventions:

<felixSophia> .. you need also say something about the root element, since it does not have a parent

<felixSophia> .. the general solution does not work for PIs

<felixSophia> SR: you could solve that problem by replacing scopeAttribute with scope

<felixSophia> .. and allowing scope to contain xpath

<felixSophia> .. so you could put its:info into a separate file

<felixSophia> SR: difference between my approach and FS approach is how to specify scope

<felixSophia> CL: FS said we should use xs:appinfo for our purposes

<felixSophia> SR: if you take FS its:info and say it is allowed in appinfo

<felixSophia> .. that is o.k. In the case of DTDs, you have to use an external file

CL: In my mind, I merged Felix' and Sebastian's work as follows
... Use xs:appInfo to hold sth. like Sebastian's its:declarations

FS: I preferred not using XPath for scoping (and crafted a convention instead) since XPath might be too tricky for some users of the ITS

RI: I am still under the impression that we are moving towards localization properties

<felixSophia> CL: I share the fear from localization properties

<felixSophia> .. looking at the use cases, e.g. localization information is put in by an author

<felixSophia> .. is not very common

<felixSophia> .. but the information will be integrated by the content manager

<felixSophia> .. we need to give a mechanism to these people

<felixSophia> .. nevertheless, the mechanisms could also to ordinary authors

<felixSophia> .. s.t. like "direct markup" vs. "marking with style like elements" vs. "external marking"

<felixSophia> RI: in the case of CSS, you need to know a different language than from css

<felixSophia> FS: how about defining at the odd level what should be used by a specific audience?

Summary of what we talked about this morning

YS: Summary of this mornings discussion

1. ODD has an example for working on ITS from an abstract representation

2. Examples for ITS information in schemas or XML instances

YS: We have identified 5 places where we may want to put ITS info
... 1. in header (see <style> element)

2. in element (see style attribute)

3. external (see reference to CSS)

4. in schema

5. on a span-like element

RI: Isn't the span-like element a special case of 2?

YS: Kind of, however, you need both since in some case you can only work with an ITS-specific span-like element

translatability information

RI: FS and myself discussed that the indicator of translatability could be captured in two was (namely either ITS language, or simple attribute)
... XHTML might be doing something similar (ie. providing two mechanisms)

SR: When talking about this, we should discuss whether both mechanims would need to provide the same expressive power

<YvesS> ..do we need a disctinction between 'localize' and 'translate'?

<YvesS> ..the distinction is who will do the change

<YvesS> ..the overall process may require the distinction even if the same personn does the work

<YvesS> ..making distinction may leads to having to take in account the process, users, etc. Things we can't know.

CL: Wrt. the indicator of translatability, we should discuss 5 dimensions
... 1. do we need two data categorize (to distinguish between localization and translation)
... 2. which values do we need (e.g. only 'yes' and 'no')
... 3. how should scoping and defaults be defined (e.g. similar to xml:lang)
... 4. to which XML entity could the data category be attached (e.g. does 'translate' make sense on elements for icons?)
... 5. how can we carry information about the origin/motivation (e.g. 'localize="yes" was set by localization engineer X)

YS: I see the need for the distinction. However, people might be confused by the complexity, and thus not use the mechanisms
... Before lunch we discussed the need for two data categories
... during lunch break, SR and CL spend some more thought on this

SR: I came up with 2 ideas

<felixSophia> CL: three values are necessary:

<felixSophia> .. yes, no, an additional value

SR: 1. translate=yes|no and translate-extension=x-
... 2. translate=yes|no|x-
... Does anyone know about other W3C specification which allow some kind of 'complex' values for attributes? XSL-FO?

RI: SVG may allow this

FS: Do we need to ask Architecture Group wrt. a recommendation related to 'complex' values for attributes?

YS: This would be helpful

RI: The x- usually is not recommended due issues with interoperability

FS: In the XSD tutorially, a mechanism for extension is demoed

CL: The issue I see here is that this is XSD-specific

<felixSophia> GO: What information do you want to express?

<felixSophia> CL: for example, if you want to have locale information, please provide more information on it

<felixSophia> .. for example, localizing into french, you might a different translation view

FS: How would you encode the translation-extension? Pointing to a URI?

<felixSophia> CL: solution: have an attribute "translate" with the values "yes" or "no"

<felixSophia> .. and an additional attribute

<felixSophia> CL: summary of the discussion: we will only get for "yes" or "no"

CL: How about 'giltAction=yes|no'?

CL [correction]: How about 'giltAction=trans|loc'

YS: What about the values? Shoud we use 'true|false' or 'yes|no'?

SR: I went for 'true|false' since it corresponds to the XSD data types

<felixSophia> ACTION: we have "yes" or "no" in the wd as values of translation, and add a note about the possibility of boolean values [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action04]

YS: We take 'yes|no' and include a note in our document what we said about 'true|false'
... What about the name of the data category for extension?

<felixSophia> CL: naming of additional information?

SR: I suggest 'translate-options'

CL: The relationship between the data categories 'translate' and 'translate-options' would be as follows:
... 'translate-options' is only allowed for 'translate="yes"'

CL [correction]: ... 'translate-options' is to be ignored if 'translate="no"'

<felixSophia> CL: we need to talk about scoping, defaulting and attachability of translate

<felixSophia> .. e.g. we should have a note that if there is no attribute available, the value should be assumed as "yes"

CL: defaulting: If no 'translate' is present than 'translate=yes' should be assumed

FS: The remarks about these facets might have to go into a 'general' section

RI: We could name the section 'defaults'

<felixSophia> ACTION: Felix to check inheritance for xml:lang (as part of his work on a wiki on xml:lang for the i18n core wg) [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action05]

<YvesS> ..should we make distinction between default for attributes and elements?

<YvesS> ..seems ok to default elements to yes and attributes to no.

CL: How do we indicate translatability for attributes in the first place?
... Yves' example uses 'its:notTranslatableAttributes'
... We could put an XPath expression in the 'translation-options' which specifies the translatable attributes

RI: The

RI [correction]: This would really overload 'translat

RI [correction]: This would really overload 'translation-options'

<felixSophia> http://www.w3.org/Guide/1998/08/teleconference-calendar#s_1779

<felixSophia> scribe: felix

summary of translatability discussion

<felixSophia> we decided that we will have a value "yes" or "no" for the translatability attribute

<felixSophia> we talked about defaults

<felixSophia> do we have a solution for PIs or comments?

<felixSophia> CL: two ideas have been discussed

<felixSophia> .. say s.t. about a list of attributes

<felixSophia> .. the other idea:

<felixSophia> .. to go back to the discussion about possible values for the translate attribute

<felixSophia> .. simple solution should be for elements

<felixSophia> .. complex solution: with "yes" and "no" and an xpath expression as a third value

<felixSophia> ACTION: for the editors to have a note in the document about scope in general (in a general section) and about the fact the scope has to be applied to translatability [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action06]

<felixSophia> CL: default, scoping and attaching translatability information has to be taken into account

representation of constraints

<YvesS> http://esw.w3.org/topic/its0506ReqConstraints

<felixSophia> use case: container size has to be described

<felixSophia> YS: another use case:

<felixSophia> restrict the number of characters for a file name

<felixSophia> SR: both of those should be in the host schema

<felixSophia> YS: for the first case it might be a problem

<felixSophia> .. because it is often messages, and you don't want to have additional data categories for them

<felixSophia> YS: for DTDs, we cannot do it

<felixSophia> SR: In tei ODD

<felixSophia> .. if you have restriction of data types

<felixSophia> .. you should generate a schematron which you can use if you rely on a dtd

<felixSophia> .. btw, does this happen often in practice?

<felixSophia> CL: Yes

<felixSophia> .. SAP has its own programming language

<felixSophia> .. and certain types of content like message strings or gui strings

<felixSophia> .. go into a data base table, which have certain restrictions

<felixSophia> .. and we have constraints like the actual character set to be used

<felixSophia> .. e.g. to allow only ascii 7 bit characters

<felixSophia> RI: length constraint is different to a character set restriction

<felixSophia> YS: for storage of a certain number of bytes / characters

<felixSophia> RI: size problems is an issue mainly for user interface texts

<felixSophia> YS: for storage it is a programming program

<felixSophia> .. so we need a distinction of user interface restriction vs. other restrictions

<felixSophia> .. e.g. some medical panels have only 16 characters

<felixSophia> .. the length restriction has a width restriction, a byte count restriction, a line number restriction

CL: We have this http://lists.w3.org/Archives/Public/public-i18n-its/2005JanMar/0043 as input to the discussion as well

<felixSophia> CL: I did a general proposal for encoding constraints

<felixSophia> .. here we have a reference to css again

<felixSophia> FS: this is also an example of "scope" description?

<felixSophia> CL: Yes

<felixSophia> .. 4 things we could learn from css:

<felixSophia> .. we have different locations for constraints

<felixSophia> .. we could have a naming scheme (e.g. s.t. related to background has "background-...")

<felixSophia> .. in terms of specifying scope, css has already a mechanism for doing it

<felixSophia> .. and we can give one or more constraint for a specific type of content

<felixSophia> SR: Another example is xsl:fo

<felixSophia> .. which uses css like information and represents them as attributes

<felixSophia> .. you don't really gain s.t. from css syntax, and you lack validation

<felixSophia> .. instead you could define an element its:constraint

<felixSophia> .. and allow several attributes which express the constraints

<felixSophia> YS: That would also be a more general solution for the scope solution

<felixSophia> ACTION: editors to add the constraints req to the scope sensitive requirements [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action07]

<felixSophia> CL: We cannot enumerate all constraints people want to express

<SebastianR> as XML, CL's example: <h1>This is about

<felixSophia> YS: but maybe we can tackle one or two

<SebastianR> <constraint

<SebastianR> Obj-type="term"

<SebastianR> reference-termBase="urn:myCompany:termBase:ProductX'"

<SebastianR> reference-conceptID="43"

<SebastianR> reference-termID="65"

<SebastianR> note-forlocalizer="Check the term base for a possible

<SebastianR> update'"

<SebastianR> constraint-allowedchars="ASCII-7"

<SebastianR> constraint-maxwidth="20"

<SebastianR> constraint-widthUnit="char"/>

<SebastianR> Document Management</h1>

<felixSophia> CL: it is the same as for the indicator of translatability, you could have "yes" and "no" and then add. values

<felixSophia> YS: it is more complex here

<felixSophia> .. we have size constraints

<felixSophia> YS: instead of the constraints attributes

<felixSophia> .. you would have the attribute for all what we are thinking of

<SebastianR> <its:constraint

<SebastianR> maxsize="16bytes"

<SebastianR> maxwidth="60px"

<SebastianR> encoding="ASCII-7"/>

<felixSophia> CL: we should have a general statement like "you need to have the translation attribute, but the maxCharWidth attribute is optional"

<felixSophia> YS: how about looking at http://www.w3.org/TR/xmlschema-2/#built-in-datatypes ?

<felixSophia> .. we then need to see if we can do that on the instance level

<felixSophia> .. what xml schema does only on the schema level

<felixSophia> YS: there are a lot of cases where you don't have documents, but data bases

<felixSophia> CL: the two worlds of data bases and documents are merging

<felixSophia> YS: data is in different reprositories, and goes through xml at some point

<felixSophia> .. a lot of constraints exist in w3c data types

<felixSophia> YS: real example from today:

<felixSophia> .. we have a customer who needs a restriction

<felixSophia> YS: it is not practical to change the schema for every type of restrictions you need

<felixSophia> CL: my understanding of the discussion: YS and RI would enumerate specific constraints like "charWidth" or "maxHeigth"

<felixSophia> .. so two action items: to come up with the list of constraints which have to be covered

<felixSophia> .. and to think about syntax, e.g. xliff

<felixSophia> ACTION: yves to fulfill the 2 action items (see above) for the constraints [recorded in http://www.w3.org/2005/09/20-i18nts-minutes.html#action08]

<felixSophia> CL: SR, what do you think about this? Is the general direction good?

<felixSophia> SR: The interesting part is to have a list of constraints

<felixSophia> .. if we agree that these things occur on many points, we just need to have a syntax for them

<felixSophia> YS: we provide a wrapping mechanism to be able to generalize it

<felixSophia> RI: in translatability, localizers and translators get involved

<felixSophia> .. in this case, other people get involved

<felixSophia> SR: We need to make decisions

<felixSophia> .. that people are able to rely on them to create tools

<felixSophia> YS: Do we need translata option? Do we need constraint-option?

<felixSophia> CL: this is a general question on how to extend

<felixSophia> YS: yes, in a way that the scoping mechanism works

mapping

<felixSophia> SR: if you use "dita" and the translate attribute, you should say that it is equivalent to the ITS information

<felixSophia> CL: mapping is targeting tools and human consumptions

<felixSophia> .. i.e. "the stuff you have to translate is marked up the following way: ..."

<felixSophia> SR: How to use this?

<felixSophia> .. e.g. if I write in DITA, what should I use? the its attribute? the dita "translate" attribute?

<felixSophia> .. it is interesting to say in the its documentation, that s.t. in DITA says the same as ITS

<felixSophia> CL: example from SAP: SAP is using its own schemas, not DocBook / DITA

<felixSophia> .. so if we had our own attribute in our schema, it might be named differently than what ITS specifys

<felixSophia> .. e.g. to say "the SAP XML indicator of translatability is this: ..."

<felixSophia> .. so the humans / the tools could act upon this information

<felixSophia> CL: for controlling localization processes

<felixSophia> .. it would be good to control the mapping

<felixSophia> SR: the mapping gets messy if is more than a pure substitution

<felixSophia> RI: Why to put that in the schema?

<felixSophia> SR: that is what I did with the equiv element which points to an XSLT which does the mapping

<felixSophia> .. DITA might use a PI to specify mapping

<felixSophia> CL: we could provide a simple mechanism for mapping e.g. one element to another one

<felixSophia> .. and having an extension mechanism

<felixSophia> FS: we have a strategy of defining extension mechanisms if we cannot reach consensus :)

<felixSophia> CL: that is a good strategy maybe :)

tomorrow

<felixSophia> 1) continue work from today

<felixSophia> 2) work on req document

<felixSophia> 3) discuss Goutam's topic

<felixSophia> 4) looking at the guidelines

<felixSophia> 5) looking at the specification

<felixSophia> 6) teleconf: should be used to summarize the work

<felixSophia> YS: Do you have a presentation, Goutam?

<felixSophia> RI: We should go through Goutam's stuff, but keep the time to a certain limit

<felixSophia> GO: it is not only for part of speech

<felixSophia> .. but more on content, e.g. content domain, sentence level information, word level information

<felixSophia> YS: how about 45 minutes?

<felixSophia> GO: it is o.k., I can talk for 2 hours

<felixSophia> YS: we will stop you :)

<felixSophia> .. so first item will be Goutam't

<felixSophia> .. then the mapping will follow

<SebastianR> mapping joke:

<felixSophia> .. we need to think about the editing of the documents as a single topic

<SebastianR> <xsl:message terminate="yes"><xsl:value-of

<SebastianR> select="."/> is mapped to "its:translate", but I do not know

I18N ITS WG F2F

20 Sep 2005

Attendees

Contents