i18n ITS working group (Oxford f2f) -- 19 Apr 2006

Inclusion mechanisms (XInclude, DITA) and ITS

going through yesterday action items and comparing to the latest draft.

On change from "may" to "should" for validation against schema: not to be changed.

<fsasaki> http://www.w3.org/International/its/itstagset/itstagset-diff-20060414.html

discussion on note below clauses for conformance type 2.

<chriLi> Who uses this conformance type: Processing expectations for ITS markup are used by any application which needs to process for internationalization or localization the element or attribute nodes captured by a data category. Examples for this type of application are: ITS markup-aware editors, or translation tools which make use of ITS markup to filter translatable text as an input to the localization process.

<rahtz> Processing expectations for ITS markup are that it will be used by any

<rahtz> application which needs to process for internationalization or

<rahtz> localization the element or attribute nodes captured by a data

<rahtz> category. Examples for this type of application are: ITS markup-aware

<rahtz> editors, and translation tools which make use of ITS markup to filter

<rahtz> translatable text as an input to the localization process.

<chriLi> Note:

<chriLi> Application-specific processing (that is processing which goes byond the computatio nof ITS information for a node) such as filtering of translatable content based on "itstranslate" is not covered by the conformance clauses below.

Discussion on XML info set and pre-processing.

felix: maybe we could say an ITS processor *may* include.

Sebastian: maybe we should remove that part.

Felix: important for DITA wrt. the conref mechanism

<rahtz> ITS implemenentations are not required to implement inclusion mechanisms such as XInclude or DITA's conref.

Christian, Sebastain: we XPath, this imply we work on the infoset.

Felix: infoset process the DTD
... and additions are possible (Schema, etc.), but not mandatory.

Sebastian: maybe we should not say anything

Felix: but we need to answer DITA's quetsion about this

<chriLi> Note: The XPath expressions used by ITS selection assume that any inclusions (such as those based on XInclude) are resolved before selection is applied.

Sebastain: so what if the included doc has rules?

Felix: that may cause issue with our precedence system.
... like in Christian's example yesterday.

YS: we can't force the processing of conref

Sebastian: it depends on how you use XInclude

felix: conref works like XInclude but on same type of element.

Sebastian: but the conref markup looks like some include mechanism.

Christian: according the Xpath spec...
... external entities are expended

Felix: but here external entities are not the conref/XInclude external content.

Christian: i wonder if where this should go.

<rahtz> Where appropriate, inclusion mechanisms such as XInclude or DITA's conref may need to be followed before ITS selections are applied

<scribe> ACTION: Christian to propose a wording for the inclusion issue (i.e. for example conref in DITA) [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action01]

coffee break

Review of the introduction

Christian: related to the XTech paper

Felix: only Christian and I know about the text

Christian: I've reworked the sections.
... moved the examples
... do we need to do the same for the specifications?
... looking at the document I send..

Felix: the example are not specific anymore, so when I integrated the section I've modified it.

Christian: I've removed the example for space issue.
... so is it ok to get rid off 1.1.2 andmove examples to 1.1.
... is makes for better reading

Sebastian: so you would merge 1.1.1 and 1.1.2

Felix: some change may be need to introduce the example.
... with "content author" not "content producer"

Another point: comparison to CSS in the paper. We have it already in some other places.

Christian: but it's valuable for comparison
... so we don't have the comparison in the normative section?

Felix: no we don't. I would prefer to have only one comparison to CSS in the spec, not 2 or 3 times.

Christian: in Motivation for ITS: I took out alle examples but one.
... for the length but also I'm not sure we would loose anything anyway.
... they all illustrate the same thing.

Felix: please, make sure to use change markup.

Christian: yes.

review for the basic Concepts section

Christian: I've added sub-sections
... we select nodes, two selections (local, global), compare to CSS

Felix: so we would keep only one comparison to CSS for the whole spec.

Christian: The 3rd section is about overriding and inheritence. we don't have it in the spec.
... about relationships between local and global selections
... also section on adding and pointing information

Felix: I'm worried: it's a lot of restructuring. difficult to implement.
... more specific change is more tedious, but we can see better the changes
... i would suggest to markup at the sentence/word level if possible.

Christian: in addition, I'd like to integrate the following:
... Referencing and pointing
... like in a new sub-section

Then for the local selection I'd like to have something about the usage of <its:span>

scribe: two types of processing: pertaining to the node, and the application-specific process.

for either Intro or basic concept

Felix: I'd like to see the detailed changes.

Sebastian: I'm bother about linking roles and uses.
... there are implications that are maybe not always true.

Felix: so look more into the 'technical strategies" rather than breaking down by roles.
... currently we look at this from a 'work perspective".

Sebastian: Things you do depend on the schema.

Christian: I'm not clear on this aspect.

Richard broke up the intro by user groups.

Sebastian: by roles is good, but I'm not sure how many different roles we have. some are misleading.

Christian: so if we present this has *one* example of possible roles

Sebastian: maybe we need other types of scenarios
... like using terms only.

felix: we need to be aware of the last call time delay.

sebastian: we need to be carefull about not doing thing too quickly just because of the Last Call deadline.

felix: we need to make sure the spec matches the charter

Sebastian: is it really needed to keep track of changes?

Felix: important for the people not in the meeting.

<scribe> ACTION: christian to integrate changes in section 1.1 and 1.2 within 2 weeks. [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action02]

Working Group contribution

Christian: I wonder if we get enough input from the whole WG. How can we make this better?

Sebastian: Is it typical?

Felix: It depends on the groups.

Yves: we need to try to get more input from the less-active members

lunch break

Schema architecture

Felix: any issue with the generated schema?

<fsasaki> ACTION: Yves to send his docbook+ITS schema and the description of it to Felix; Felix to integrate that into the tagset draft [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action03]

SR: we need to make sure all the source has a description.

FS: what that description should be?

CL: something already existing.

SR: a short description sentence.
... everything (almost) has a <desc> element you can use.

<scribe> ACTION: Felix to produce descriptions for each entry in the schema. [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action04]

<scribe> ACTION: Sebastian to get rid of "empties" from generated schema [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action05]

SR: in what sense the schema is normative?
... do we need to say that somewhere?

FS: wrong to fix the order.
... this is a normative section though
... that section is refered to from the conformance section

CL: one possible comment we could get is that we use one group per attribute
... I'm sure we can explain this if needed.
... maybe extent the comment in the schema?
... Might be helpful to add info about where to find additional info on how the schema is generated.

<scribe> ACTION: Sebastian and Felix to add comment in ODD to have it inside the generated schema to explain how it was created. and where to get more info. [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action06]

FS: so how do you like the way the schema is now?

SR: maybe I would simplify it.

FS: if we use name 'value' would be confusing.

SR: maybe we can not do the same thing for everything

FS: but that would mean changes in the Draft
... worried about the prose.

SR: do you agree we have to drop the namespace on the rules?

FS: yes

SR: they must have different descriptions since they do different things.

FS: in some aspect they are common.

YS: I have no opinion

SR: the points we care is the rules element, the span, the ruby, and the local attributes
... the rest does not matter really.

SY: yes, just make just attributes are broken down by data cat.

FS: what about the difference between its:translate and translate in rules for example?

SR: rules is an island

<fsasaki> <meta><its:rules translate="yes" its:translate="yes"><info>...

<fsasaki> <meta><rules xmlns="whatever" translate="yes" its:translate="yes"><info>...

<fsasaki> <meta><rules xmlns="whatever" translate="yes" its:translate="no"><info>...

SR: YS: I though its:translate and translate inside an ITS element would be the same.

SR: no

<scribe> ACTION: YS to change its implementation to fix its:translate/translate [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action07]

<scribe> ACTION: felix to change the ODD to have no-prefixed attributes at the rules element (with SR help). [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action08]

<scribe> ACTION: all make sure "rules" is using non-prefix attributes in all samples and test [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action09]

<chriLi> More feedback on the generated XSD:

<chriLi> - typing incomplete

CL: for locInfo we don't have a type for example
... (attribute)
... some attributes appear with a type some other do not.
... there are also the slectors without types

SR: we should explicitely set all these to string type

<chriLi> - default values not in the XSD

CL: they should probably have defaults

SR: did we discuss what the default value should be?

YS: difference between default when rule is not there and default when the rule is there but without the attribute.

<chriLi> - does there need to be sth. in span?

<scribe> ACTION: Felix to specify the "requiredness" of attributes when needed in the schemas [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action10]

CL: also: we're not required to put anything

<chriLi> - only ruby element within span, not dir?

YS: probably ok since text may have to be deleted without deleting tags (during translation for example)

CL: also we can't put the language in span

FS: we should say in the techniques that xml:lang should be used then

<chriLi> - foo:date not possible on/within rules

CL: also, we would not provide metadata for <rules>.
... I tried it, but cannot do it

YS: that is because the default schema does is not open. you have to change the schema to allow this.

FS: yes, we discussed this when we talked about extension. opening the schema like this would reduce the validation capability

CL: may be not a good thing to say people to use extnesion but not make it easy by default

FS: that's why our schemas are not normative.

CL: We should probably have a note to indicate that in the spec.

YS: +1

SR: We should have a license text in the schema.

<scribe> ACTION: Felix to check how license should be handled in the schema. [recorded in http://www.w3.org/2006/04/19-i18nits-minutes.html#action11]

Tea break

<fsasaki> http://www.w3.org/2006/04/19-i18nits-minutes.html

how to make ITS known

<fsasaki> summary of the discussion: think of whether we want to have reviews as a means for getting ITS adopted, and what is necessary in the next charter for it

implementations / test suites

<fsasaki> yves: we wanted to break it up into different pieces

<fsasaki> .. real life examples, versus made up examples

<fsasaki> .. everything should be valid

<fsasaki> felix: we could have a link to the test suite

<fsasaki> sebastian: for things which are linked to the test suite, we use <egXML xlink:href=".."/>

<fsasaki> .. for the rest, we use what the have now

<fsasaki> felix: how about test suite structure?

<fsasaki> yves: could be one folder, e.g. spec-directory/testsuite/

<fsasaki> .. with all lof the examples, and distinguish them with names

<fsasaki> yves: I would not worry about the test suite structure now, e.g. how to fill a table like http://www.w3.org/International/its/tests/

<fsasaki> .. the spec is not the collection of the test suite, but only some examples are used in the test suite

<fsasaki> christian: we need markers which say "this gives a negative result, this a positive one"

<fsasaki> .. e.g. version information errors

<fsasaki> sebastian: for errors like XPath which does not match s.t. it is hard to test s.t.

<fsasaki> christian: how to test conformance of schemas?

<fsasaki> felix: I think we don't need to do that

<fsasaki> sebastian: !?!

<fsasaki> christian: test suites should be not bound to conformance

<fsasaki> felix: why not?

<fsasaki> christian: we need to make sure that the purpose of the test suite is clear

<chriLi> http://www.w3.org/XML/Test/xmlconf-20031210.html

<chriLi> http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0148

<fsasaki> christian: we need a relationship between the test suite and the features

<fsasaki> .. and that as many features as possible features are covered

<fsasaki> .. e.g. : instance documents with conflicting ITS versions

<fsasaki> felix: that is an error condition

<fsasaki> yves: the matrix we produced

<fsasaki> felix: e.g. translatability global

<fsasaki> yves: we need to test also if e.g. ns is correctly supported

<fsasaki> .. or having termRef and termRefPointer

<fsasaki> .. however, I am not sure if they have to be in the matrix

<fsasaki> felix: http://www.w3.org/International/its/itstagset/itstagset.html#conformance-product-processing-expectations has to be tested

<fsasaki> christian: we have to keep track: "this test is for the following feature, here is the expected result"

<fsasaki> yves: we could have test files which generate errors, saying "if you process this, it should generate an error"

<fsasaki> .. for example the cooccurrence of pointer and not pointer attributes

<fsasaki> .. or having namespace qualified and not namespace qualified attributes at rules element together

<fsasaki> .. or testing that precedence does work, or that link files

<fsasaki> felix: we don't need error tests to move forward in the w3c process?

<fsasaki> yves: it would be very good to have them

<fsasaki> .. but it is not necessary (if we don't have time) to have them before recommendation

<fsasaki> .. a possible topic for a next charter: extensive tests

i18n ITS working group (Oxford f2f)

19 Apr 2006

Attendees

Contents