This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2915 - Clarify relationship between host vocabulary markup data cats and ITS data cats
Summary: Clarify relationship between host vocabulary markup data cats and ITS data cats
Status: CLOSED FIXED
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: LastCall
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Felix Sasaki
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-02-22 15:49 UTC by Christian Lieske
Modified: 2006-07-24 09:13 UTC (History)
0 users

See Also:


Attachments

Description Christian Lieske 2006-02-22 15:49:37 UTC
(see also bug 2877 (terminology data category))

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?

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?

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">PlateBroiler</term> ...
</body>

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)
Comment 1 Yves Savourel 2006-04-13 03:31:45 UTC
> 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'.
Comment 2 Felix Sasaki 2006-04-13 06:25:52 UTC
(In reply to comment #1)
> > 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?

I don't know if Christian is asking for a text in the normative data category section (sec. 6), or in the introduction. I would say such text could go in the introduction or in the techniques, but not in the normative part.

As for the rest of Yves' answers: +1.
Felix
Comment 3 Felix Sasaki 2006-04-20 08:14:22 UTC
closed during http://www.w3.org/2006/04/19-i18nits-regular-call-minutes.html
Comment 4 Felix Sasaki 2006-07-24 09:13:25 UTC
Closed, no further action necessary.