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 3058 - ITS inheritance mechanism versus other inheritance mechanisms (e.g. DITA): Need for clear distinction
Summary: ITS inheritance mechanism versus other inheritance mechanisms (e.g. DITA): Ne...
Status: CLOSED FIXED
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: WorkingDraft
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Felix Sasaki
QA Contact: Felix Sasaki
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-29 14:32 UTC by Felix Sasaki
Modified: 2006-07-24 10:35 UTC (History)
0 users

See Also:


Attachments

Description Felix Sasaki 2006-03-29 14:32:10 UTC
Part of DITA sub TC, discussion of proposal for the xml:lang attribute:
[[
       -- We're talking about the root topic element.
        -- If xml:lang is on document element, then the highest level topic 
            element inherits xml:lang. Likewise, <topicref> should inherit 
            from <map> (if no parent overrides xml:lang) or from nearest 
            parent that overrides the xml:lang setting of the root element.
        -- In case of contradiction between xml:lang setting on <topicref> and 
            xml:lang on <topic>, the <topicref> setting does not apply to the 
            <topic>. In other words, the map does not override any xml:lang 
            on the <topic>.
        -- Discussion whether xml:lang on map should apply to the topics...
        -- Discussion of translation workflow...
        -- Need map file for each target language.
        -- Proposal must clarify the following:
            - xml:lang on <map> is applied to the map.
            - xml:lang on <map> does not affect topics.
            - if different xml:lang values exist on map and topic, topic setting
                overrides.
            - add use cases]]

The usefulness of our global rules might be quite limited for DITA, due to DITA's specific inheritance mechanism (see discussion above). We need to make clear for DITA and other markup vocabularies with specific inheritance mechanisms, how ITS fits into the picture. IMO we don't need to adapt to them. However, a detailed example of the relation between inheritance in DITA versus inheritance in ITS would be good. I'd propose Christian to deliver one :)
Comment 1 Yves Savourel 2006-04-07 20:16:43 UTC
As far as I understand there is no issue here.
Shall we close this bug?
-ys
Comment 2 Felix Sasaki 2006-04-10 15:50:29 UTC
(In reply to comment #1)
> As far as I understand there is no issue here.
> Shall we close this bug?
> -ys
> 

I had a look at 
http://norman.walsh.name/2005/10/21/dita#conref
and I am still wondering: what happens with translatability information if I apply the conref mechanism of DITA?

Examples from DITA: compare
1) <note conref="#topic1/usefulnote"/>
versus
2) <note><p>...</p></note>
if I write a rule like
<its:translateRule its:select="//note" its:translate="no"/>
in ITS, the translatability information would inherit to the <p> element in the case of 2), but not in the case of 1).
However, if I understand DITA correct, 1) and 2) should behave the same in terms of translatability.
Am I missing something, or do we have to tell the DITA folks that they can't apply ITS in a useful way if they use @conref? 
Comment 3 Yves Savourel 2006-04-10 16:23:47 UTC
ITS is applied to the *source* document, without pertending knowing anything about how the documents are merged/split/reorganized to form a final document.

This is a limitation that comes with any type of compound-document system, not just DITA. But there is not much we can do about it. Anyone can create document from bit and pieces of other documents using various methods: there are no way we could forsee all cases.

Re-usability has many advantages, but it has also drawbacks.
Comment 4 Felix Sasaki 2006-04-12 07:32:16 UTC
(In reply to comment #3)
> ITS is applied to the *source* document, without pertending knowing anything
> about how the documents are merged/split/reorganized to form a final document.
> 
> This is a limitation that comes with any type of compound-document system, not
> just DITA. But there is not much we can do about it. Anyone can create document
> from bit and pieces of other documents using various methods: there are no way
> we could forsee all cases.
> 
> Re-usability has many advantages, but it has also drawbacks.
> 
However, what we could do is show workarounds for these cases, like saying "put all DITA files in one directory and apply the rules to them." That would in practice be leveling of the difference between the compound and non-compound version of <note>.
Having such an example would make it easier to sell ITS to DITA.
Comment 5 Felix Sasaki 2006-05-01 07:00:40 UTC
Resolved by paragraph about inclusion mechanisms in the terminology / definition section, see http://www.w3.org/International/its/itstagset/itstagset.html#notation-terminology .
- Felix
Comment 6 Felix Sasaki 2006-07-24 10:35:41 UTC
Closed, no further action necessary.