<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

Quick test suite update

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_> http://htmlpreview.github.io/?https://raw.github.com/finnle/ITS-2.0-Testsuite/master/its2.0/testSuiteDashboard.html#tests-current-state-details

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

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_> http://services.w3.org/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2FInternational%2Fmultilingualweb%2Flt%2Fdrafts%2Fits20%2Ftools%2Fxslt%2Fdisco-for-its20.xsl&xmlfile=https%3A%2F%2Fwww.w3.org%2FInternational%2Fmultilingualweb%2Flt%2Ftrack%2Fapi%2Fdump%3Ffull&content-type=&submit=transform

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

Elements Within text

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

Best Practice: XLIFF mapping: LQI/LQR

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