[Minutes] MLW-LT Call 2013-05-15

Hi all,

I tried to clean up last week's minutes, see

and below as text. Let me know if something is missing / wrong.




       [1] http://www.w3.org/

                                - DRAFT -

                                MLW-LT WG

15 May 2013



    See also: [3]IRC log

       [3] http://www.w3.org/2013/05/15-mlw-lt-irc


           Yves, Ankit, chriLi, Karl, marcis, Jirka, leroy,
           DaveLewis, Milan

           Pedro, Maurcio, Pablo, Felix




      * [4]Topics
          1. [5]Quick test suite update
          2. [6]extensibility in its:rules
          3. [7]Elements Within Text
          4. [8]Best Practice: XLIFF mapping: LQI/LQR
      * [9]Summary of Action Items

    <scribe> scribe: kfritsche

    dF_: main topic consensus to publish last call



    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_: ITS2.0 is moving to second last call, so participants best
    practice, which is in the IG maling list, which is chaired by
    ... 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

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

    <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

    <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

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

    <trackbot> Created ACTION-529 - Formulate change for elements
    within text, because of script-tag [on David Lewis - due

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


    <Yves_> The initial reasoning is here:


    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

    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

Summary of Action Items

    [NEW] ACTION: daveL to formulate change for elements within
    text, because of script-tag [recorded in
    [NEW] ACTION: Jirka to propose change for schema changes for
    extensibility [recorded in
    [NEW] ACTION: Yves to propose spec change to address
    extensibility in general [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [23]scribe.perl version
     1.138 ([24]CVS log)
     $Date: 2013-05-20 08:31:07 $

      [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [24] http://dev.w3.org/cvsweb/2002/scribe/

Received on Tuesday, 21 May 2013 15:45:16 UTC