See also: IRC log
<scribe> scribe: fsasaki
<scribe> agenda:
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
http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0010.html
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
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
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
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> 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: http://www.w3.org/TR/its20/#its-schemas
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
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
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
christian: felix and I gave a
presentation related to ITS, for Tekom annual conference in
stuttgart
... presentation is online, in german
<chriLi> 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
12 january?
<YvesS> yes
<chriLi> yes
adjourned
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-i18n-its-ig/2014Dec/0010.html Got date from IRC log name: 08 Dec 2014 Guessing minutes URL: http://www.w3.org/2014/12/08-i18nits-minutes.html People with action items:[End of scribe.perl diagnostic output]