- From: Felix Sasaki <fsasaki@w3.org>
- Date: Mon, 8 Dec 2014 18:26:32 +0100
- To: public-i18n-its-ig <public-i18n-its-ig@w3.org>
See
http://www.w3.org/2014/12/08-i18nits-minutes.html
and below as text. Next call will be 12 January.
- Felix
[1]W3C
[1] http://www.w3.org/
- DRAFT -
ITS IG
08 Dec 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0010.html
See also: [3]IRC log
[3] http://www.w3.org/2014/12/08-i18nits-irc
Attendees
Present
dF, felix, renatb, philr, YvesS, christian
Regrets
serge
Chair
felix
Scribe
fsasaki
Contents
* [4]Topics
1. [5]roll call
2. [6]standoff markup and xml:id
3. [7]progress of xliff - its
4. [8]back to standoff topic
5. [9]schema listings in the (xliff) spec
6. [10]rules file
7. [11]space annotation, language annotation
8. [12]implementations needed
9. [13]AOB
10. [14]next call
* [15]Summary of Action Items
__________________________________________________________
<scribe> scribe: fsasaki
<scribe> agenda:
roll call
checking attendeeds
<dF> Felix, is the goto up yet?
<dF> it says waiting for organizer
<dF> OK, just double-checking that I am on the right goto id
[16]http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014
Dec/0010.html
[16] http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0010.html
standoff markup and xml:id
david: related to standoff markup - in loc quality isussue, and
provenance there is xml:id on the standoff wrapper
... the xml:id is used as reference from inline markup
... if standoff is needed
... two related issues - first, we allow xml:id in extensions.
Do we want it in a module?
... if it was an nmtoken it would not need to follow the xml:id
syntax
... it could be simply nmtoken
... that was one thing I was wondering
felix: is that all you had related to standoff?
david: yes, that's it
yves: about xml:id and standoff
... I think we address that in the fragment identification
... we said you could use xml:id
david: yes, we say that, not to dictate to extensions
... for a module we can make it nmtoken
... no need to work with uniqueness
yves: the uniqueness is always there
... it does not work if it is not an xml:id
david: reference would be just a reference, not a fragment
identifier
yves: not sure - we always point with fragment identier
... not sure, have to think about it
david: sure, will explore to make this an nmtoken and write a
mail to both public lists about this
... with the options
progress of xliff - its
david: today's call was meant as status check
... we are delayed but delay is not too bad
... although ITS module is delayed, it is the farest advanced
from the approved features
... advanced validation, ITS module, internal matches
... so whole progress is delayed
... we don't need to worry that ITS has to jump on the train
not being complete
... I am picking up speed transfering mapping to the spec
... first draft should be feature complete strawman by
christmas
... what others should do: develop the rules file
... that should be implemented and circulated
... then what is also needed: a conformance clause for the
module?
... we have several ways to tackle conformance for the module
... that is connected to the rules file - we need a good
description of the markup simplification for the ITS processors
... it cannot be guaranteed what happens if the simplification
does not succeed
yves: we also need implementation on the XLIFF side
... otherwise the features are not used
... if the data categories are not use from the XLIFF side, it
has not been validated as working
david: will talk with dave lewis from trinity if they can
provide an implementation
phil: we have xliff 2 on the roadmap for ocelot, will not
happen before christmas
... not sure if deploying library from yves counts?
david: I think previously, when we did ITS2 implementations, we
established re-using libraries is a valid way to provide
reference implementations
... the think with oasis is: we need three implementations /
statements of use
... one of them needs to be oasis member
... requirement is relaxed
phil: if there were an opportunity to support xliff 2.0, if we
exercise some module features it would be good?
david: indeed
... the only module for XLIFF 2.1 so far is ITS module
... we will do again statements of use as a questionaire, like
we did for XLIFF 2.0
back to standoff topic
yves: in ITS we don't specify where the standoff element should
be
... for XLIFF it may be wise to limit the location of the
element
... there is loc quality issue and provenance who use the
information
... for LQI information is in source or target
... and we would not share information between units
... that means, different instances of information are per unit
... was wondering if we should limit the location
david: you postulate that in the wiki, think it is a good idea,
to restrict it to the same unit
yves: ok. so how about provenance - is that an obstacle, e.g.
for phil?
... when you have a standdoff annotation, if it is at the end,
you have to do several passes, that is annoying with a stream
reader
phil: currently ocelt writes this at the end of the file
element
felix: probably due my misunderstanidng of xliff 1.2 extension
points
david: for xliff 2.1 we could restrict provenance standoff for
unit - would not make sense to make them lower?
... you can also have change tracking on any level
<philr> I also had the feeling it was due to the reader/writer
we are using
david: I postponed to do provenance and MT confidence
... so location for provenance - would make sense to restrict
standoff for inline provenance to be in the same unit
... structural provenance could be in any place
... or we could say standoff must not be used for higher than
unit
... that would be an issue if there is a use case for overlap
on higher level
phil: our use case is specific to unit level
david: we could use two standoff extension points: file + unit
... unit would be the highest to put inline standoff
... if we said standoff is only avail. for inline on unit, and
for file on structural annotations
... I will implement it in the spec text like that and you can
look at it
schema listings in the (xliff) spec
david: schema listings make the spec biiig
... spec gets bigger and bigger if we have schema listings
... schema listing is an informative listing of the artifact
... schema file will still be linked from the spec
... schema listing is informal. Is the schema listing relevant
for readers / implementers of the spec?
phil: is there an example you can point to?
david: sure
... will provide a link to xliff 2.0 spec, you can see them
included
... oasis confirmed it is ok to dump them
<dF>
[17]http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-c
ore-v2.0-os.html
[17] http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html
david: see appendix a - schemas + catalogues listings
phil: will check with people about this
david: please post answer later
phil: ok
yves: about schemas again - does anybody work on ITS module
schema?
david: no, AFAIK
... tom is working on transforming documentation into XSDs
... may ping him to start looking at it this week
... hope to have schematrons ready in january
felix: that would be relevant for the validation module, right?
david: yes - validation is an orthogonal issue. XSDs are the
only things that we need for the module
... for the advanced validation we must provide them for the
new module
felix: jirka provided schematron files for ITS2, these may be
useful input
see schematron files here:
[18]http://www.w3.org/TR/its20/#its-schemas
[18] http://www.w3.org/TR/its20/#its-schemas
rules file
felix: we started a rules file in the wiki
david: sure, cannot be finished until the prose is finished
<dF> its:any
<dF> generic
<dF> itsm:generic
david: in the strawman I am working on, I am using itsm:generic
... seems to be more systematic
<dF> itsm:nonTerm
felix: is that related to the rules file?
david: it is - if you parse the annotations you can recognize
them as ITS if the have the "itsm:generic" type
<dF> its
<dF> itsm
david: itsm makes clear that this is the xliff thing, not the
w3c thing
<dF> generic
yves: using generic instead of any is because of ...?
... generic in the case of annotation means: when you add some
stuff
... we can discuss that forever I think
... there are many reasons to choose one or the other
... it is an arbitrary string I guess
... XLIFF core implementer is used to calling generic
annotations generic
... for the xliff we have the type since we need a type
... but it is not appearing in many documents since it is the
default
space annotation, language annotation
david: we discussed whether these should be in the ITS module
or in a different modjule
... not sure - good to be aware of it
... currently I am implementing it as a singel module
... yves, it is possible to have several modules with the same
namespace? the same "itsm" namespace
... or would that violate some of the XLIFF constraints?
yves: don't think that it matters - namespaces don't have to
match the modules
... we already use different modules anyway, like for xml:lang
etc.
david: I guess I will finish implementing that in one bulk, and
we can break it up in January
implementations needed
felix: for moving forward you need XLIFF implementations, not
ITS only, right?
david: that is related to conformance clause
... I think that something supports the module means: just
support reading ITS data category
felix: hard to separate these things - ocelot would do both
david: ocelot would be great
... but we need at least three implementations
... we will need an extra agent
yves: I disagree with that
david: why woudl you think it is bad
yves: you would have an XLIFF processor, not an ITS processor
david: indeed
... what if the processor woudl do the sm transform?
yves: there is cases in which you cannot do the transformation
david: we need normative language to describe that
felix: we should take time until things are worked out
david: from the point of view of the module you could define
separate constraints
christian: have not looked into discussion too often. What I
heard about conformance + conformance clauses what not clear so
far
... I understood that either xliff or ITS would change or add
conformance clauses, but that may be a misunderstanding
felix: hope that there would be no change for the existing
specs - xliff 2.0 and its 2.0
david: it is OK for xliff module to add conformance
requirements, they must not be with general conformance
requirements
AOB
christian: felix and I gave a presentation related to ITS, for
Tekom annual conference in stuttgart
... presentation is online, in german
<chriLi>
[19]https://www.w3.org/community/ld4lt/wiki/File:Tekom-sasaki-l
ieske-2014-1119.pdf
[19] https://www.w3.org/community/ld4lt/wiki/File:Tekom-sasaki-lieske-2014-1119.pdf
<dF> must not be in conflict ;-)
christian: other item - felix and I translated / broadend the
scope of presentation that will appear soon in Multilingual
<dF> in 2015 Multilingual Resource directory will have a
standards reader again with update on xliff 2.0 and its 2.0
next call
12 january?
<YvesS> yes
<chriLi> yes
adjourned
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [20]scribe.perl version
1.140 ([21]CVS log)
$Date: 2014-12-08 17:15:51 $
__________________________________________________________
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[21] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at [22]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/kevin@wripl.com//
Succeeded: s/list of open issues related to xliff - its/standoff markup
and xml:id/
Succeeded: s/directory/directory will have a standards reader again with
update on xliff 2.0 and its 2.0/
Found Scribe: fsasaki
Inferring ScribeNick: fsasaki
Present: dF felix renatb philr YvesS christian
Regrets: serge
Agenda: [23]http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014D
ec/0010.html
Got date from IRC log name: 08 Dec 2014
Guessing minutes URL: [24]http://www.w3.org/2014/12/08-i18nits-minutes.h
tml
People with action items:
[23] http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0010.html
[24] http://www.w3.org/2014/12/08-i18nits-minutes.html
[End of [25]scribe.perl diagnostic output]
[25] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 8 December 2014 17:26:41 UTC