See also: IRC log
<scribe> scribe: kfritsche
dF_: main topic consensus to publish last call
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013May/0125.html
dF_: moving topics around
leroy: we have two test per
category and reached over 80%
... did some updating to elements within text and translate
dF_: we have conformance for each data category
<dF_> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013May/0125.html
dF_: ITS2.0 is moving to second
last call, so participants best practice, which is in the IG
maling list, which is chaired by yves
... everyone is welcome to join this
chriLi: 80% sounds like there is a gap
dF_: target and commitment is
100%
... but important for conformance is two test for each data
category, which is required by W3C
kfritsche: changes because of HTML5 got the coverage down
dF_: current conformance is high enough to get to second last call
<dF_> 0) Topic: extensibility in its:rules
dF_: Cocomore/Linguaserve using
ITS extension in its:rules
... this would result in a schema change
... but consensus sound good
<Yves_> Can we have also non-ITS attributes in ITS elements? (with same processing as non-ITS elements: they can be ignore)
Jirka: I can do the schema changes, for this also a small change in the spec is needed
dF_: no open last call comments
Jirka: this is not a normative change its just a clarification
chriLi: I have problems to spotting it
kfritsche: its the its:readinessrules, the example is wrong there to use its, it has to be itsx
Yves_: Can we have also non-ITS attributes in ITS elements? (with same processing as non-ITS elements: they can be ignore)
<Yves_> just with its-extension namespace would be ok
Jirka: maybe yves is proposing to allowing additional attributes to its:rules
<Yves_> yes, that's what I'm asking
<Yves_> statement
<Yves_> either allowing just its-extension or any namespace would be fine with me. I'm just asking if we can have non-ITS attributes in ITS elements
dF_: trying to summarize, everyone is okay with adding its extension (itsx)
Jirka: we should allow extension attributes for its rules as well
<Yves_> Sound good to me too.
[kfritsche agrees with Jirka]
dF_: whats with deleting
Jirka: we don't define any processing, so we shouldn't say anything about it
<Yves_> I agree with Jirka. just say extensions can be ignored.
dF_: i'm not sure if the changes
needed for this are normative
... we could go for the second last call, if we think that this
doesn't need a normative change
... we haven't addressed extensibility at all before
... so i would suggest to move consensus to last call for next
week, after this change is done
<Yves_> I can try
dF_: jirka, yves, karl are the most interested in the topic, can you propases spec and schema changes till next week
Jirka: i could do the schema change
dF_: consensus should be reached till end of week
<dF_> ACTION: Yves to propose spec change to address extensibility in general [recorded in http://www.w3.org/2013/05/15-mlw-lt-minutes.html#action01]
<trackbot> Created ACTION-527 - Propose spec change to address extensibility in general [on Yves Savourel - due 2013-05-22].
<scribe> ACTION: Jirka to propose change for schema changes for extensibility [recorded in http://www.w3.org/2013/05/15-mlw-lt-minutes.html#action02]
<trackbot> Created ACTION-528 - Propose change for schema changes for extensibility [on Jirka Kosek - due 2013-05-22].
dF_: with this we can't do a consensus to publish last call
skipping topic: Consensus to publish Last Call
<Yves_> related to last call..
<Yves_> We may also need/want to change Element Within text: Silvia has a good point about <script> that it should be nested rather than within-text http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2013May/0133.html This would change the text in the specification But maybe it's just a minor change that can be dealt with in during the second last call.
dF_: can we maybe address this to, till next week? can anybody address this?
<scribe> ACTION: daveL to formulate change for elements within text, because of script-tag [recorded in http://www.w3.org/2013/05/15-mlw-lt-minutes.html#action03]
<trackbot> Created ACTION-529 - Formulate change for elements within text, because of script-tag [on David Lewis - due 2013-05-22].
dF_: best practices are not WG, this are for the IG
<Yves_> the reasoning is in the email.
<Yves_> see also http://lists.w3.org/Archives/Public/public-i18n-its-ig/2013May/0012.html
<Yves_> The initial reasoning is here: http://lists.w3.org/Archives/Public/public-i18n-its-ig/2013May/0003.html
dF_: most of the partners now working on the 1.0 mapping, but tilde needes also a 1.2 mapping
<marcis> We support (officially) only 1.2
<marcis> The question from our side is, whether there will be now changes? Or ... we leave everything as is? Our module currently adds mrk tags as it is required by the mapping doc.
daveL: in situation like tilde adding annotation into a existing xliff file, they have to use the mrk
<marcis> In HTML we actually do not generate a useless <span> tag if there is one already ...
<Yves_> Marcis: it should affect TAWS much see my answer of this morning. "Note also that this would not affect Tilde's implementation too much, since TAWS mostly *adds* annotations to the existing XLIFF document, "
daveL: yves point is good, but its hard to add this in already generated xliff files
dF_: the change does affect you or not?
marcis: it definitely affects us,
because we always use mrk
... for HTML we check if a element is already exists and add
attributes there, instead of adding a span
... it would be no problems to use the xliff types for us, if
we agree on this
dF_: do you check for its attributes only in mrk or on all elements
marcis: for us its not a problem
to do this and to add ITS annotations to already existing
elements
... problem is currenlty the timing, because we are stop
working on it at end of may
... and we need time to implements changes
... so it would be good to resolve it very soon
dF_: this has to be solved asap,
so resume this discussion on the mailing list as we are at the
top of the hour
... would be best to have a consensus till next week for
this
... hopefully we can publish last call next week
... meeting adjourned