[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Cascading of xml:lang attribute
I would think in such a situation, where you have to manage a large number of languages, the only rational process is to mark each piece of content with its language. The potential for assigning the wrong language to a piece of content via cascading, processor defaults, or any other mechanism is higher in such cases than it is for the customer with only one or two languages. If xml:lang cascaded from maps to topics when there's no explicit xml:lang on the topic, you'd wind up with content in the output marked with the wrong language via cascading, and we would have to call that valid DITA processing even though it's obviously incorrect. The xml:lang and other locale-related attributes are different from other cascading attributes because they are descriptive, not prescriptive; they describe the content as it is, not metadata for how it should be processed. Topics are in a language, and they're in that language no matter what map references them, and no matter whether they specify xml:lang or not. Allowing a map - or anything else - to impose a language setting invites outcomes that are simply wrong. I suspect, but can't say for sure, that the language in the spec about processor defaults is there because something has to establish a language eventually, but it's not a very good substitute for assigning language markers on your content. Chris On 8/3/10 6:07 PM, "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote: > Hi Dave, > > For teams which publish primarily in one language, setting a "good" default > for the processor or putting xml:lang in the template is not a big burden. > However, consider a team that publishes in a dozen locales. That team needs to > set the locale parameter for the processor up to a dozen times and get it > right each time. You can automate builds to avoid having to set parameters > over and over, but many adopters do not have automated build processes, > especially in the the early stages of adoption. > > The question is whether processors should apply the xml:lang of the primary > map *if that is the only place where xml:lang is defined*. Why should the > answer be no? I'm aware that changing the xml:lang on a map or topic does not > change the language of any other sub-topics or sub-maps. However I donıt see > how that (obvious) fact is relevant to this question. > > Cheers, > Su-Laine > > > -----Original Message----- > From: Helfinstine, David [mailto:dhelfinstine@ptc.com] > Sent: Tuesday, August 03, 2010 1:33 PM > To: dita@lists.oasis-open.org > Cc: Robert D Anderson; Su-Laine Yeo > Subject: RE: [dita] Cascading of xml:lang attribute > > Greetings, > > The xml:lang should be considered an attribute set in each document. There are > other language type attributes like @dir and @translate that are also document > attributes. They also do not cascade from map to map or map to topic or topic > to sub topic, etc. These might be important when processing so it would not > necessarily be xml:lang alone that would need to be considered. As has been > mentioned, changing the xml:lang on a map or topic does not change the > language of any other sub-topics or sub-maps. > > The comments regarding setting the xml:lang in every document can be overcome > by setting a good processor default. If the processor default in a French > environment is ³fr² then it might be reasonable that the processor default > would be ³fr² unless a different xml:lang is encountered in a map or topic. If > however one of the French documents were put into a different language map > then the processor default would probably be set to that language. The French > author would have to remember to put the xml:lang=²fr² in the French topic to > keep that from happening. Having the xml:lang=²fr² on the topic tag would > alleviate the problem in the first place. For those users who use templates, > it might be great to include in the template the xml:lang already set to a > decent default value. That way no worries! > > Before the DITA 1.2 the cascading of attributes was not defined. There was > talk of inheritance in DITA 1.1 and there was the one reference to xml:lang > regarding topicref and the actual topic. But as a whole this topic was not > defined rather than DITA 1.2 being a change to the way they behaved. > > Thanks. > > - Dave H. > > Dave Helfinstine > DHelfinstine@ptc.com > > -----Original Message----- > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] > Sent: Tuesday, August 03, 2010 2:56 PM > To: Robert D Anderson > Cc: dita@lists.oasis-open.org > Subject: RE: [dita] Cascading of xml:lang attribute > > Thanks Robert. > > We've received some quite strongly-worded comments from DITA users that having > to set xml:lang on every single topic file would be an enormous hassle. For > the case of a mostly-French document that pulls in one English topic, it is > reasonable to ask users to set xml:lang="fr" once on the map, and > xml:lang="en" once on the English topic. However I don't see why we would also > require users to set xml:lang="fr" on every French topic if they want those > topics to be processed in French. > > I see this as being a substantial change over the DITA 1.1 spec which adds > work for users, and I can't see the practical benefit. > > Su-Laine > > > -----Original Message----- > From: Robert D Anderson [mailto:robander@us.ibm.com] > Sent: Tuesday, August 03, 2010 12:33 PM > To: Su-Laine Yeo > Cc: dita@lists.oasis-open.org > Subject: Re: [dita] Cascading of xml:lang attribute > > Trying to remember the discussion of this - I believe that your reading of > the 1.2 spec is correct. > > I think the idea was that the language is a property of the document itself > that travels with the document, and cannot be set or reset from above. For > example, if you have a map with all French topics, but then reference an > existing English topic somewhere else that does not set xml:lang, the fact > that you're referencing it from a French map does not make the topic > French. Following the spec's recommendation to ensure xml:lang is on the > root element of every document helps bypass this issue and any resulting > confusion. > > Robert D Anderson > IBM Authoring Tools Development > Chief Architect, DITA Open Toolkit > > > > "Su-Laine Yeo" > <su-laine.yeo@jus > tsystems.com> To > <dita@lists.oasis-open.org> > 08/03/2010 03:11 cc > PM > Subject > [dita] Cascading of xml:lang > attribute > > > > > > > > > > > Hi everyone, > > > A bug report for the DITA Open Toolkit has raised some interesting > discussion: > > > https://sourceforge.net/tracker/?func=detail&atid=725074&aid=3038532&group_id= > 132728 > > > Users need to know if they need to set the xml:lang attribute only in their > primary map, or for every topic. Developers of processors need to know if > processors should look at the map when deciding what locale to use when > displaying topics. > > > Say you have a <note> element in a DITA topic that is referenced by a DITA > map. My reading of the DITA 1.1 spec is that language should be determined > as follows: > > > 1) Get xml:lang from the <note> element. If xml:lang is not defined there, > get it from the closest ancestor within the topic. > > > 2) If xml:lang not defined in an ancestor of <note> within the topic, get > it from the <topicref> in the map. > > > 3) If xml:lang not defined in the <topicref>, get it from closest ancestor > of the <topicref> within the map. > > > 4) If xml:lang is not defined in any ancestor of the <topicref> within the > map, the processor should assume a default value. > > > However, the draft DITA 1.2 spec contains the sentence ³The @xml:lang value > does not cascade from one map to another or from a map to a topic², which > seems to imply that the language should be determined as follows: > > > 1) Get xml:lang from the <note> element. If xml:lang is not defined there, > get it from the closest ancestor within the topic. > > > 2) If xml:lang not defined in an ancestor of <note> within the topic, the > processor should assume a default value. > > > Is this the intention? > > > Su-Laine > > > Su-Laine Yeo > Solutions Consultant > > > JustSystems Canada, Inc. > Office: 778-327-6356 > syeo@justsystems.com > > > www.justsystems.com > > > XMetaL Community Forums: http://forums.xmetal.com/ > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]