ITS IG -- 08 Dec 2014

<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

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> 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

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> 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

- DRAFT -

ITS IG

08 Dec 2014

Attendees

Contents