OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dita] Navtitle and locktitle (reprise)

Robert D Anderson <robander@us.ibm.com> wrote on 2007-01-17 01.35.43:
> Also, I'm not sure that adding a third value would be easier
> to understand.

(Well, I did consider briefly suggesting an inheritable version of @locktitle="no" for the sake of symmetry, but I thought better of it lest it cloud my point.)
> I think you would have one value on an
> attribute that will inherit, vs. two values that do not.

I pulled this sentence out from your message because I think it sums up our differences of opinion perfectly.  For me, having an attribute value mean the same thing on all elements is important.  For others, what element the attribute is on is just as important.  Perhaps I dislike that because element names in DITA are, in the face of specialization, not the Precambrian Shield of Stability that they are in other XML schemas.

In any case, this isn't such a big deal that I am going to kick up a big argument about it.  I just want us to be consistent across the "do what I mean"/"say what you mean" spectrum.

> For map references - you're right that the effect needs to be stated. I
> would think that if you include a map while using locktitle on the
> reference, then that is equivalent to setting locktitle on the target map.
> Otherwise, if the map you pull in has a global locktitle setting, that
> global locktitle setting would be used. That's my initial impression of
> what would be the most logical, so please argue otherwise it seems odd.

That seems reasonable within the context of how @locktitle has been proposed, yes.

Deborah Pickett

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]