Re: [All] domain data category section proposal, please review

Hi Yves, all,

would it help to resolve this by saying "if there are several values for
'Domain' available in the source content, applications SHOULD concatenate
their string values by comma &#2C;".

I know what you said we shouldn't do anything about this - but having
authored a few DocBook and other technical documentation formats, I have
the impression that the order of the "Domain" values in such formats is not
always significant. So if you just take the first one or leave it to the
applications which one to take, some useful information might be lost.

Felix

2012/7/29 Yves Savourel <ysavourel@enlaso.com>

> Hi Felix, Dave, Declan, all,
>
> Just a minor note:
>
> While implementing Domain I ran into the interesting case of an its:domain
> limitation. I don't think we should do anything about it, but it may be
> worth noting.
>
> When looking for an XML example I turn to DocBook, and looked for the
> elements equivalent to the DC:subject property. The first example I found
> used <subjectterm> for the domain value, and you could have several of
> them. So we end up with a possible case like this:
>
> <article xmlns='http://docbook.org/ns/docbook'>
>  <info>
>   <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="2.0"
>    xmlns:d="http://docbook.org/ns/docbook">
>    <its:translateRule selector="//d:subjectset" translate="no"/>
>    <its:domainRule selector="/d:article"
>     domainPointer="d:info/d:subjectset/d:subject/d:subjectterm"
>     domainMapping="'Electronic Publishing' epub, 'SGML (Computer program
> language)' CompLang"
>    />
>   </its:rules>
>   <title>Example of subjectset</title>
>   <subjectset scheme="libraryofcongress">
>    <subject>
>     <subjectterm>Electronic Publishing</subjectterm>
>    </subject>
>    <subject>
>     <subjectterm>SGML (Computer program language)</subjectterm>
>    </subject>
>   </subjectset>
>  </info>
>  <para>Text of the document</para>
> </article>
>
> No problem, we just implement the ITS processor so it handle the result as
> a list of domain values rather than a single per selected node. So I've
> done that.
>
> Then I tried to implement Domain in XLIFF 1.2. We can use non-XLIFF
> attributes in the <trans-unit> element, so it is logical to just use
> its:domain to store the domain extracted from the original document there.
>
> The problem: its:domain holds a single value and we have several values to
> pass on. So either we just pass on a single value, or we have to use a
> non-ITS element or attribute to hold a list. I choose to just pass on the
> first value.
>
> <xliff version="1.2" xmlns="urn:oasis:names:tc:xliff:document:1.2">
> <file original="/EX-domain-docbook.xml" source-language="en-us"
> target-language="fr-fr" datatype="xml">
> <body>
> <trans-unit id="1" xmlns:its="http://www.w3.org/2005/11/its"
> its:version="2.0" its:domain="epub">
> <source xml:lang="en-us">Example of subjectset</source>
> <target xml:lang="fr-fr">Example of subjectset</target>
> </trans-unit>
> <trans-unit id="2" xmlns:its="http://www.w3.org/2005/11/its"
> its:version="2.0" its:domain="epub">
> <source xml:lang="en-us">Text of the document</source>
> <target xml:lang="fr-fr">Text of the document</target>
> </trans-unit>
> </body>
> </file>
> </xliff>
>
> My guess is that multiple domain values for a single selected node will
> not be frequent enough to outweigh using directly the ITS attribute.
> Hopefully that will do.
>
> Cheers,
> -yves
>
>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow

Received on Monday, 30 July 2012 03:42:29 UTC