See also: IRC log
<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.
<fsasaki> http://www.w3.org/2012/07/05-mlw-lt-minutes.html
Felix: If no comments on the minutes, we should move on.
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.
<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.
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].
<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].
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