RE: [all] Question on mapping best practices [Issue-55]

Hi Felix,

 

Yes, we obviously need to document such namespace and have a schema for it.

In my view the wiki table is just a working document.

We should probably produce something like a Note if that’s what make most sense.

 

But that’s not urgent: for now it’s good enough to go through the data categories and make sure there is no show stopper.

 

One thing that seems to be clear is that the absence of extensibility in XLIFF <mrk> is a major headache, and likely not just for the ITS mapping. So we’ll try to resolve that on the XLIFF side. If that can go through it would help things a lot.

 

-ys

 

 

From: Felix Sasaki [mailto:fsasaki@w3.org] 
Sent: Saturday, October 27, 2012 12:20 AM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org
Subject: Re: [all] Question on mapping best practices [Issue-55]

 

 

2012/10/26 Yves Savourel <ysavourel@enlaso.com>

Shaun's resolved the question by eliminating the ITS case.
So we'll go with a 3rd namespace in the cases where all ITS attributes can't be used for some reasons.

 

 

Will that 3rd namespace be documented in the mapping document or somewhere else? After all the purpose is to have compatibility between ITS and XLIFF metadata approaches, no? 

 

Felix

 

 


For documenting the conversation: I think Dave scribed our call.

Cheers,
-yves

From: Felix Sasaki [mailto:fsasaki@w3.org]
Sent: Friday, October 26, 2012 12:12 PM
To: Yves Savourel
Cc: public-multilingualweb-lt@w3.org
Subject: Re: [all] Question on mapping best practices

Hi Yves, all,

a side note: would it be possible to document the XLIFF mapping conversation? I don't mean the current state of the mapping, but the discussion and meetings (e.g. in Seattle and the call today). Without any minutes or at least summary it is hard to contribute or judge on proposes to change ITS. The announcement that there is a discussion
http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Oct/0249.html
and a follow up call doesn't provide a lot of details.

Wrt to your comments and ITS mechanisms: why use them at all? Why not specifying the mapping in general, e.g. in a separate profile of ITS "how to use ITS in XLIFF"? We then won't need to use any ITS mechanisms at all - an ITS implementation can use the mapping or not.

Above answer may be not enough, let's take it from where.

Best,

Felix
2012/10/26 Yves Savourel <ysavourel@enlaso.com>
Hi all,

While mapping ITS to XLIFf we ran into cases of mapping that may occur elsewhere and for which an ITS guideline may be helpful.

Here is the case:

The localization note has two pieces of information:  a) the text of the note and b) a type (description|alert)

When mapping an inline note to XLIFF we can use this:

<mrk mtype='x-itsNote' comment='[text of the note]' its:locNoteType='alert'>...</mrk>

Or this:

<mrk mtype='x-itsNote' comment='[text of the note]' ZZZ:locNoteType='alert'>...</mrk>

The comment attribute is where XLIFF is expected to put the note, and because there is no equivalent to the note type we use a non-XLIFF attribute there. The question is can/should we use the ITS attribute or another one?

In both cases if we want to process the file with an ITS processor, we have to use global rules:

<its:locNoteRule selector="//mrk[@its:locNoteType='alert']"
 locNotePointer="@comment" locNoteType='alert'/>

<its:locNoteRule selector="//mrk[@its:locNoteType='description']"
 locNotePointer="@comment" locNoteType='description'/>

or

<its:locNoteRule selector="//mrk[@ZZZ:locNoteType='alert']"
 locNotePointer="@comment" locNoteType='alert'/>

<its:locNoteRule selector="//mrk[@ZZZ:locNoteType='description']"
 locNotePointer="@comment" locNoteType='description'/>

I think both would work.
But we're not sure if the best thing to do for the local attribute is to use a native ITS attribute or define a new namespace and use something from there.

Any thoughts?

Thanks,
-yves






--
Felix Sasaki
DFKI / W3C Fellow







 

-- 
Felix Sasaki

DFKI / W3C Fellow

 

Received on Saturday, 27 October 2012 10:50:40 UTC