MLW-LT Working Group

12 Jul 2012


See also: IRC log


felix, shaun, Yves, Arle, milan, Pedro, Guiseppe



<fsasaki> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0154.html

Felix: There are not many people on the call today, so we will discuss things, but not make any decisions.

last weeks minutes

<fsasaki> http://www.w3.org/2012/07/05-mlw-lt-minutes.html

Felix: If no comments on the minutes, we should move on.

reminder topics 2,3,4

Felix: Coming back to actions, there are various comments. Jirka made comments on the draft, as did Jörg Schütz. We need volunteers to put them into the draft.

Arle: Count me in on that.

Felix: Just let the list know what edits you want to make.
... It shouldn't take too much time.

parameter for rules

<fsasaki> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0090.html

Felix: I think we are close to a conclusion here. The URL I pasted in had some comments.
... Does anyone on the call have any issues on this parameter for rules or can we move on? Note that these are guidance for implementers.
... Any other comments?


No comments were made

Felix: This will require more discussion, perhaps between Yves and Shaun.

<fsasaki> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Jul/0107.html

Felix: That is the latest mail on this from Yves, which is a reply to a mail from Shaun. Can someone summarize?

Yves: The original proposal was to look at a possible topic in the document, but Shaun brought up the question about multiple targets in the document or replicating part to make a multilingual document. Shaun makes a convincing argument that we cannot deal with both as a single data category.
... We need to see who will implement what I proposed, but if there is interest in the multilingual document proposal by Shaun we should also proceed with that.

Shaun: I have working code that replicates elements to create multilingual documents using xml:lang. I have a method with limitations that could be solved by adopting additional metadata. I've not tried to do this with a real format, I don't want to pursue it unless someone else is interested.

<fsasaki> <its:targetPointerRule selector='//source' targetPointer='../target'/>

Felix: So we would be OK with moving forward with the one that Yves mentioned using XPath and regular expression, as described in the example I pasted in and the mail I linked.
... You counted implementations in the Okapi integration with Declan.
... And XLIFF roundtripping.

(Not sure I got that right).

Yves: They would actually use the same implementation underneath things.

Milan: We would use the Tikal as used in M4Loc.

<Yves_> Link to Tikal: http://www.opentag.com/okapi/wiki/index.php?title=Tikal

Felix: I think it is OK to say that they are two different implementations, even if they are just different wrappers around Tikal. We could accommodate that with more specific test cases.

Yves: We need to test the library as well.
... Do I need to do a call for consensus on this?

Felix: You did not on targetpointer. So write a mail pointing to the thread saying that we have everything resolved and see if everyone agrees.

Yves: I will write the definition, if that helps.

Felix: Sounds good.

special requirements

Felix: We had a lot of discussions here. Let me summarize.
... First, Cocomore wanted a way to list forbidden characters. Then there was a requirement to specify maximum length. I tried to push Schematron as a solution for this, but I was wrong. Yves and others told me that the checking is external to XML, in a database, so Schematron doesn't make sense. So we need to pass the metadata about checking.
... We started with proposals by Guiseppe. What is missing is consensus about the forbidden characters, whether it should be a list or regular expressions.
... Michael mostly wanted a list of characters, but I was concerned about the syntax of regular expressions. That's where we are.

Yves: I kind of agree with you that the work in Microsoft in XLIFF covers more than forbidden characters: it is far more. Also, a simple list of characters would do the job for the things we have in mind. But if we add what Arle proposed, it would make things much easier, even just using the bracketed ranges.
... I think every regex engine supports that.
... That would be the first step, then looking at some additional patterns like /w, as long as we are working with common features.

<fsasaki> scribeNick: fsasaki

arle: even adding dash and brackets and inverse with the carrot would make it simpler, maybe that's all that's needed
... unicode range selectors adds a whole layer of complexity

yves: yes, and these are not supported by all reg ex engines

arle: correct

<scribe> scribeNick: Arle

Felix: If we develop a regex solution, will users then have two solutions. Assume we have some metadata in XLIFF, will it be different from the ITS solution?

Yves: I don't think it will be an issue. Right now there is nothing in the XLIFF pipeline for this. I pointed to Microsoft only because they are using extensions with regex. I think I shouldn't have given that example because it opened a can of worms.

Felix: jan Nelson said he would check in Microsoft about this. Should we wait for that with a simple regex solution?

Yves: I don't think it hurts to wait, but I can contact Kevin and Yves to ask about this.

<scribe> ACTION: Yves to contact Jan and Kevin at Microsoft to see what their use or regex is and whether it overlaps with what we do. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action01]

<trackbot> Created ACTION-167 - Contact Jan and Kevin at Microsoft to see what their use or regex is and whether it overlaps with what we do. [on Yves Savourel - due 2012-07-19].

quality errors

<fsasaki> scribeNick: fsasaki

Arle: felix and I discussed this
... we want to be able to point to quality definitions that are available in machine readable form
... but we don't know yet how these will look like
... Felix said: at this point we can just have a pointer
... and leave details out
... at DFKI we are working on defining how that should look like
... Phil's concern is probably: the information is not in the document

<scribe> scribeNick: Arle

Felix: One aspect is that if we put something with the current consensus in the document, I'd be worried that we have open value lists for things like error type, severity, or other aspects. I would be worried that each vendor puts in their own error types.
... InteroperabilityNow is working on concrete values, so we might end up with IN, ITS, and DFKI types.
... That is my concern if we allow anything there. We have no way to constrain this lacking a clear definition.

<fsasaki> scribeNick: fsasaki

arle: here I am coming back to the registry notion
... that doesn't exist yet either

yves: the problem with the registry:
... it is half dynamci
... in some cases the user creates its own type of errors
... in many checker tools
... there is no way to cater that in a registry
... maybe there is need for open data for this scenario
... other things about the "type"
... we thought of having two levels of informaiton
... one very generic, one defined sub categories
... which is user definable
... which may have a registry
... if you don't understand the 2nd part, you can use the 1st part

<Arle> scribeNick: Arle

Felix: It's a bit like language tags where you have a standard part, but it can be extended with content at the end of the tag.
... But the question still arises, how does it relate to the values being created in groups like InteroperabilityNow.

Yves: We would have to define a list that we can't change. The open part would allow people to have their own.

Felix: I want to make one proposal to move forward. Let's take this data category into account -- it is very important -- and we will define local markup and take more time (until November) to see how much interoperability we can achieve on the XLIFF side and InteroperabilityNow. We need someone to work on that in the next months.
... That would be Arle, to confirm that it works with the values that are developed there.

<fsasaki> scribeNick: fsasaki

<Arle> Yves: On this topic, not necessarily on the value and category, I want to understand on the global rule.

arle: after discussing between I and felix
... I thought it may not hurt to make it globally available, but don't have a strong opinion

<Arle> scribeNick: Arle

Yves: For everything we can implement it globally or in ITS. So that would be a first. So is there a good justification. If it doesn't happen, then using a referenced element in XLIFF, an ITS processor might not understand the results, even though it came from ITS.

Felix: The scenario you describe is what I see, being able to use the category in a non-ITS namespace. For that reason, I think it makes sense to have a global definition. So that, e.g., in HTML5 its- has the same meaning as its: Then you could have a global rule that its-error = its:error in an XML serialization. Maybe it's general for HTML, but global rules help to simplify implementation without specific HTML5 processors.

Yves: One other question. You have qa-error attribute applying to the scope of the element it is applied to. But if I look at the conceptual semantics and we use a reference element with an inline <span> that refers to where we define the ITS elements, then the elements do not work because they have content that does not apply to the element but to the container.

Felix: Is this specific to quality or to other things?

Yves: It applies to everything.

Felix: It comes up in quality due to its complexity, but we have other complex items, like localization note. So I'm wondering if we need to look at this more generally. Do we need more on the quality topic.

Yves: If you say we need global rules, then that is fine.

Felix: is it OK with you, Arle, to define local rules for now and take time until November to see what others are doing.

<scribe> ACTION: Arle to follow up on quality and compatibility with XLIFF and Interoperability Now. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action02]

<trackbot> Created ACTION-168 - Follow up on quality and compatibility with XLIFF and Interoperability Now. [on Arle Lommel - due 2012-07-19].

reference topic

Felix: We already started this, but let's come back to it.
... One thing I was not clear about on the thread: Yves: do you see this as important only to ITS or to other areas like language tagging as well?

<Pedro> q Thank you Felix, I am already here

<fsasaki> thanks

Yves: For example, when we have non-well-formed elements that are broken down, then we don't say that the attributes apply to the content, but to the element.
... If we follow a namespace, we need to follow the semantics of the namespace.

<scribe> ACTION: Yves to summarize the reference discussion in a mail. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action03]

<trackbot> Created ACTION-169 - Summarize the reference discussion in a mail. [on Yves Savourel - due 2012-07-19].

Felix: XLIFF 2.0 is moving in the direction of this reference mechanism. Is this a hot topic that needs to be decided now in XLIFF? If we don't have it in ITS, will it keep us from creating XLIFF 2.0+ITS applications?

Yves: Current thinking in XLIFF is to use references. I haven't explored the global rules mechanism, so maybe there is a way to solve it in how you define the global rules. So the short answer is that it is kind of important.
... At least to me because I don't understand how I would do it otherwise.

Felix: Is there anywhere you can point to to show the XLIFF consensus and how XLIFF files point to external resources?

Yves: Note that it is a consensus of the inline markup SC, not the whole committee.

Felix: If nothing else, you get ten minutes of your time :-)
... I will be on holiday next week, so I'll have to wait until a week from Monday to look at what is going on.

Pedro: I am working on some templates for documentation to the Commission.
... It will give a cover and so forth so that we are not late in delivering.
... We have a meeting on the 25th with Cocomore to close some things. It is a conference of the work package.

<Yves_> bye

<fsasaki> meeting adjourned

Summary of Action Items

[NEW] ACTION: Arle to follow up on quality and compatibility with XLIFF and Interoperability Now. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action02]
[NEW] ACTION: Yves to contact Jan and Kevin at Microsoft to see what their use or regex is and whether it overlaps with what we do. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action01]
[NEW] ACTION: Yves to summarize the reference discussion in a mail. [recorded in http://www.w3.org/2012/07/12-mlw-lt-minutes.html#action03]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.136 (CVS log)
$Date: 2012/07/12 15:19:55 $