W3C home > Mailing lists > Public > public-i18n-its@w3.org > April to June 2006

[Bug 2915] Clarify relationship between host vocabulary markup data cats and ITS data cats

From: <bugzilla@wiggum.w3.org>
Date: Thu, 13 Apr 2006 03:31:45 +0000
To: public-i18n-its@w3.org
Message-Id: <E1FTsYb-00078k-QT@wiggum.w3.org>


------- Comment #1 from ysavourel@translate.com  2006-04-13 03:31 -------

> 1. What if the host vocabulary already has markup related to 
> terms (see for example DITA and DocBook)? Do we recommend 
> keeping it and mapping it via a documentRule? If so: Can this 
> recommendation be generalized, and thus for example become 
> part of the introduction to data categories?

I would say yes. To all questions of 1.
But should such recommendation go in the specification or in the techniques?

> 2. What if the host vocabulary and our ITS markup related 
> to terms only share some commonalities? Example: The DITA 
> "term" element allows more than just one attribute with 
> additional information? Do we suggest to
> a. move stuff from ITS into host vocabulary
> <dita:term its:dir="ltr">PlateBroiler</dita:term>
> b. move stuff from host vocabulary into ITS
> <its:term dita:platform="CoolOS">PlateBroiler</its:term>
> Or do we suggest something completely different?

Mmm... I suppose the ITS data categories are quite specific: if the host markup
provides less, the ITS data category cannot be represented by the host markup.
If the host markup provides more, it includes the meaning of the ITS data
category and therefore we use the <rules> to associate the host markup with the
data category.

> 3. What if we have a clash of the information from the 
> namespace of the host vocabulary and the ITS namespace? Example
> <head>
> <documentRule its:term="yes" its:termSelector="//dita:term">
> </head>
> <body>
> <p>The highly visible <dita:term dita:translate="no">Plate
> Broiler</term> ...
> </body>

I'm not sure if we have a clash here: <dita:term> is associated to ITS
terminology, and that's it. (dita:translate could be associated to ITS
translatability if we wanted too, but both rules don't clash(?) One can declare
a term being not translatable. It's up to the ITS processor to choose what data
categories it wants to support.

> 4. What if the host vocabulary and ITS differ with 
> regard to one of the following:
> 4.1 content model (for example PCDATA vs. mixed)
> 4.2 data type (for example NMTOKEN vs. CDATA)

I would say 4.2. probably does not matter: the ITS rules use XPath and
values/content (not type). For example, at least from a DOM viewpoint, we don't
know if in dita:translate='yes' 'yes' is a NMTOKEN or a CDATA, it's just the
string 'yes' as described by the XPath expression, so there is not type-based
relation between the 'yes' of dita:translate and its:translate.

For 4.1. I'm guessing it does not matter either. For example an
its:locInfoPointer can point to an attribute or to a element content. ITS does
not define what the actual note is made of: it's just a node.

I think these two questions would be more important for 'real mapping' but our
current simple 'association' mechanism is more 'forgiven'.
Received on Thursday, 13 April 2006 03:32:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:07 UTC