[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Cascading of xml:lang attribute
I'm mostly okay with the wording, but we have to be very careful about our use of terminology that we don't make things more confusing. Comments below. > -----Original Message----- > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] > Sent: Thursday, 2010 August 26 20:11 > To: dita@lists.oasis-open.org > Subject: RE: [dita] Cascading of xml:lang attribute > > In the TC meeting a couple of weeks ago I think we came to consensus on > the following: > 1) @xml:lang does not cascade from maps to topics > 2) It is reasonable for a processor to set its default language for > processing by looking at the @xml:lang value on the primary map file > > Currently the spec only mentions #1, so people who unlike us have not > spent 10 hours combing over difference between cascading and setting a > default may be confused by a processor which implements the behaviour > described in #2. > > Page 77-89 of the PDF file in CD03 currently says: > > "The @xml:lang attribute specifies the language (and optionally the > locale) of the element content. The @xml:lang > attribute applies to all attributes and content of the element where it > is specified, unless it is overridden with @xml:lang > on another element within that content. When no @xml:lang attribute is > specified, the processor should assume a > default value." > > I propose changing this to: > > "The @xml:lang attribute specifies the language (and optionally the > locale) of the element content. The @xml:lang > attribute applies to all attributes and content of the element where it > is specified, unless it is overridden with @xml:lang on another > element within that content. If no @xml:lang attribute is specified in You cannot use the word "specified" here. An "attribute specification" is a specific term that implies the presence of an attribute assignment in a particular start tag (and does not account for a possible default being assigned by the schema). Furthermore, "specified in" doesn't make sense, especially "specified in a ... map" which could be taken to be talking about any assignment anywhere within a map document. It's hard to be precise short of using infoset terminology (which will admittedly confuse everyone except a few geeks), so the best I can do is suggest something informal like: If the @xml:lang attribute on the document (outermost) element of a map or top-level topic has no value, the processor... paul > a given map or top-level topic, the processor should assume a > default value. The default value of the processor may be fixed, or it > may be derived from a run-time parameter, configuration file, other > setting, or from the content itself, such as the @xml:lang attribute on > the primary map file." > > 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/ > > > > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Monday, August 09, 2010 7:24 AM > To: dita@lists.oasis-open.org > Subject: RE: [dita] Cascading of xml:lang attribute > > The xml:lang attribute doesn't--and shouldn't--cascade > (for a variety of reasons discussed in the past). > > We shouldn't be saying anything about processor defaults > in the standard other than to say that they are implementation > dependent. > > Since generated text is usually going to be in the target > language and generated text is usually defined in a stylesheet, > one reasonable processor default is to do something based > on the stylesheet being used. > > Another reasonable processor default is to use the system > locale value. > > I think all Dave was saying was that yet another possible > processor default is to do something based on some value > in the primary map. But I believe he was only making the > point that there are multiple ways by which a processor > could reasonably determine an implementation dependent > default in the unrecommended case that a topic is missing > an xml:lang assignment. > > We do not want to be suggesting that cascading xml:lang > values is the correct--or even reasonable--thing to do. > > paul > > > -----Original Message----- > > From: Robert D Anderson [mailto:robander@us.ibm.com] > > Sent: Monday, 2010 August 09 9:11 > > To: Su-Laine Yeo > > Cc: dita@lists.oasis-open.org > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > Hi Su-Laine, > > > > > David H. said that he'd be OK with having a processor pick up the > > > xml:lang on the map and using it to set the processor default. This > > > seems to me to be functionally equivalent to having the xml:lang > > > attribute cascade. > > > > I don't think that is actually functionally equivalent - at least, if > I > > read David's words very literally. I think David is suggesting that > the > > xml:lang attribute on the primary map element itself - that map being > > the > > starting point of this information set - could establish a default > for > > the > > entire information set. > > > > If an attribute cascades, then it may be reset at different levels in > > the > > map. If one branch is in English, and one branch in Russian, > different > > values would cascade from that point, and those branches could > override > > the > > original value set at the map level. > > > > David - am I right in seeing a distinction between your suggestion > and > > this > > interpretation? Were you suggesting that the default come from the > map > > element in the main map, the map element in any referenced map, or > (as > > with > > other cascading attributes) any level of any map? > > > > > I propose changing this to: > > > "Processors may treat the @xml:lang value as cascading from one map > > > to another or from a map to a topic. An @xml:lang value specified > in > > > a map may be used if @xml:lang is not defined in child maps or > > > topics. However, an @xml:lang value specified in a map must never > > > override explicit @xml:lang values specified in other maps or in > > topics. > > " > > > > I'm not entirely comfortable with that, because to me it reads > exactly > > like > > our other definitions of cascade, except that it's a may instead of a > > must. > > If we do end up declaring this type of cascade, I'd prefer to simply > > state > > that it may cascade, rather than redefining cascade behavior. > > > > Personally I'm more comfortable with David's suggestion (as I read > it), > > which seems closer to the spec intent. The spec currently refers to a > > processor default, which to me implies a single value for all topics > > that > > do not specify xml:lang. I think it's logical to get that default > from > > the > > root element of the map, just as it's logical to get the default from > a > > setting in the processing software. However, if the value cascades, > we > > may > > end up with several defaults, depending on where in the map a topic > is > > referenced. > > > > Robert D Anderson > > IBM Authoring Tools Development > > Chief Architect, DITA Open Toolkit > > > > "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote on 08/06/2010 > > 03:45:09 > > PM: > > > > > "Su-Laine Yeo" <su-laine.yeo@justsystems.com> > > > 08/06/2010 03:45 PM > > > > > > To > > > > > > <dita@lists.oasis-open.org> > > > > > > cc > > > > > > Subject > > > > > > RE: [dita] Cascading of xml:lang attribute > > > > > > > > Hi everyone, > > > > > > I went back to the DITA users who had told me they didn't want to > > > have to put xml:lang on every topic, and they more or less agreed > > > that putting xml:lang on every topic would not be a huge burden. So > > > I believe we have consensus, which we didn't have before, on the > > > following points: > > > - Setting xml:lang on each topic will assist in reuse across maps, > > > faceted search, and possibly authoring, and is strongly > recommended. > > > - Setting xml:lang on each topic is not too much of a burden for > > adopters. > > > > > > Yay :) > > > > > > However: > > > - Accidents happen. If a team tries to put xml:lang on every topic > > > but fails in 0.1% of cases, that is approximately one error every > > > 500-1000 pages. > > > - Some processors treat xml:lang as cascading. With the current > > > wording of the draft 1.2 spec, these processors would be required > to > > > stop this behavior. > > > - There are teams with legacy content that does not have xml:lang > on > > > every topic, because they produce single-language deliverables and > > > their processors have thus far picked it up from the map. > > > > > > A good point has been raised that the map might not have the > correct > > > xml:lang for describing the language of a topic that doesn't itself > > > include xml:lang. However if the xml:lang in the map is different > > > from the processor's default, which is more likely to correctly > > > describe the language of the topic: the map, or the processor > > > default? The processor default is more likely to be correct if we > > > assume that a topic that does not declare xml:lang is likely to be > > > in English. However in an environment where people are making an > > > effort to declare xml:lang in all topics including English ones, I > > > would think that accidental omission of xml:lang would be equally > > > likely for all languages. > > > > > > David H. said that he'd be OK with having a processor pick up the > > > xml:lang on the map and using it to set the processor default. This > > > seems to me to be functionally equivalent to having the xml:lang > > > attribute cascade. > > > > > > The draft 1.2 spec currently says: > > > "The @xml:lang value does not cascade from one map to another or > > > from a map to a topic, and an @xml:lang value specified in a map > > > does not override @xml:lang values specified in other maps or in > > topics. > > " > > > > > > I propose changing this to: > > > "Processors may treat the @xml:lang value as cascading from one map > > > to another or from a map to a topic. An @xml:lang value specified > in > > > a map may be used if @xml:lang is not defined in child maps or > > > topics. However, an @xml:lang value specified in a map must never > > > override explicit @xml:lang values specified in other maps or in > > topics. > > " > > > > > > How does that sound? BTW, the draft 1.2 spec already has plenty of > > > wording to encourage people to set xml:lang on every topic. > > > > > > Su-Laine > > > > > > > > > -----Original Message----- > > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > > > Sent: Thursday, August 05, 2010 12:47 PM > > > To: bryan.s.schnabel@tektronix.com; dita@lists.oasis-open.org > > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > > > No, that's just what I had in mind, Bryan. Thanks! I've been aware > > > of XLIFF for some time, without really looking into it. > > > > > > The DITA 1.2 spec talks about this issue at "2.1.3.9.1 The > @xml:lang > > > attribute". In particular, it says: "The @xml:lang value does not > > > cascade from one map to another or from a map to a topic...." So a > > > value of @xml:lang that is set in a map applies only to content > that > > > is immediately contained within the map, such as a title. > > > > > > Su-Laine's discussion looks at cascading, a top-down notion, from > > > the other direction, bottom up. If @xml:lang is unspecified on some > > > element (a note, in her example), look to the parent element, and > do > > > so recursively within the topic, but don't look outside the topic > to > > > the map. If no value is set anywhere in that walk up the DOM, > assumea > > default. > > > > > > I suppose a processor in fact might more efficiently work from the > > > top down. When you encounter an element with @xml:lang set, push > the > > > current value onto a stack and use the new value on down the DOM > > > from there until it's overridden or you exit the current branch > > > dominated by the element that carried that value; whereupon take > the > > > earlier value back off the push-down stack. When you exit a topic, > > > the last value that you can take off the stack is the system-set > > default. > > > > > > (BTW, I just noticed a couple of typos in the section on use with > > > @conref/@conkeyref: "If the reference element does not have an > > > explicit value for the @xml:lang attribute, the effective value for > > > its @xml:lang attribute is determined by using the standard > > > @xml:lang inheritance from the referenced source.." Should be > > > referenced element, and a single period. Do I have to go make a > > > formal comment?) > > > > > > Su-Laine was reporting that users don't want the overhead of > setting > > > @xml:lang on every topic. The spec seems to suggest that this be > > > automated in some way ("applications should") but also makes > authors > > > responsible ("authors are urged"): > > > > > > "Applications should ensure that every highest level topic element > > > explicitly assigns the @xml:lang attribute. Authors are urged to > set > > > the @xml:lang attribute in the source language so that the > > > translator may change it in the target language. Because some > > > translation software does not permite translators to add elements, > > > the absence of the @xml:lang element from the source language may > > > result in higher administrative costs for translation." (I assume > > > that "may change it in the target language" means "may change it in > > > a copy (?) of the topic in which the content is translated to the > > > target language") > > > > > > This gives one strong reason why users might want to bite the > bullet > > > and find a way to tag every topic. There is also the issue of > > > sharing content to an environment where a different default > > languageprevails. > > > > > > /B > > > > > > > -----Original Message----- > > > > From: bryan.s.schnabel@tektronix.com > > > > [mailto:bryan.s.schnabel@tektronix.com] > > > > Sent: Thursday, August 05, 2010 2:18 PM > > > > To: Bruce Nevin (bnevin); dita@lists.oasis-open.org > > > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > > > > > Hi Bruce, > > > > > > > > Regarding your question: > > > > > > > > > can't you send fragments smaller than a topic for translation > if > > > > > that's all that has changed? > > > > > > > > I think that depends on your method of sending topics out for > > > > translation. I see this as an absolute real-world > > > > requirement. And I think a great way is to use the open > > > > standard for translation, XLIFF, as part of your DITA process. > > > > > > > > I hope to resurrect the DITA Translation SC (under the DITA > > > > Adoption TC) as soon as I can marshal the bandwidth. One of > > > > the things members of that SC have talked about in the past > > > > is evaluating the use of XLIFF as a best practice for > > > > translating DITA. Using XLIFF as your Interchange File Format > > > > when translating DITA topics enables exactly what you are > > > > talking about. The idea is that all of the topics referenced > > > > by a given map would be transformed into an XLIFF file (XLIFF > > > > is a preferred file format for translation providers and is > > > > natively consumable by translation tools). > > > > > > > > So if fragments within the topic need to be translated the > > > > XLIFF file can identify the strings that need to be > > > > translated, and lock (but provide for context) the strings > > > > that do not need translation. Here's a little sample: > > > > > > > > For this topic segment: > > > > <section> > > > > <title>Electric Guitars</title> > > > > <p translate="no">Lester William Polsfuss aka Les Paul was > > > > a pioneer of the development to the Solid > > > > body Electic Guitar and modern recording > > > > technologies.</p> > > > > <p translate="yes">Clarence Leonidas Fender, also known as > > > > Leo Fender, moved the development of Electric > > > > Guitars into the modern era, with smaller, > more > > > > portable solid body Electric Guitars.</p> > > > > </section> > > > > > > > > This XLIFF segment would trigger the translator to translate > > > > the second paragraph, but provide the first paragraph as a > > > > locked, for context only topic fragment (note the @state > > attribute): > > > > > > > > <group id="section-3"> > > > > <trans-unit id="title-4"> > > > > <source>Electric Guitars</source> > > > > <target state="needs-translation" xml:lang="de">Electric > > > > Guitars</target> </trans-unit> <trans-unit id="p-5"> > > > > <source>Lester William > > > > Polsfuss aka Les Paul was a pioneer of the development to the > > Solid > > > > body Electic Guitar and modern recording technologies. > > > > </source> > > > > <target state="final" xml:lang="de">Lester William Polsfuss > > > > alias Les Paul war ein > > > > Pionier der Entwicklung hin zur Solidbody-E-Gitarre und > moderner > > > > Aufnahmetechniken. > > > > </target> > > > > </trans-unit> > > > > <trans-unit id="p-6"> > > > > <source>Clarence Leonidas Fender, also known as Leo Fender, > > > > moved the development of Electric Guitars into the modern era, > > with > > > > smaller, more portable solid body Electric > > > > Guitars.</source> <target state="needs-translation" > > > > xml:lang="de">Clarence Leonidas Fender, also known as Leo Fender, > > > > moved the development of Electric Guitars into the modern era, > > with > > > > smaller, more portable solid body Electric > > > > Guitars.</target> </trans-unit> </group> > > > > > > > > Hopefully this answer doesn't abstract too far beyond the > > > > scenario you had in mind. > > > > > > > > - Bryan > > > > > > > > -----Original Message----- > > > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > > > > Sent: Thursday, August 05, 2010 8:56 AM > > > > To: JoAnn Hackos; Chris Nitchie; Su-Laine Yeo; Helfinstine, > > > > David; DITA TC > > > > Cc: Robert D Anderson > > > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > > > > > I've not been directly involved with this, but can't you send > > > > fragments smaller than a topic for translation if that's all > > > > that has changed? Or are other means used to identify just > > > > those parts that need the translator's attention? > > > > > > > > A topic may have different xml:lang values on different > > > > fragments in it. Quotations, citations, and legal > > > > requirements for bilingual environments come to mind. > > > > > > > > /B > > > > > > > > > -----Original Message----- > > > > > From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com] > > > > > Sent: Wednesday, August 04, 2010 4:57 PM > > > > > To: Bruce Nevin (bnevin); Chris Nitchie; Su-Laine Yeo; > > Helfinstine, > > > > > David; DITA TC > > > > > Cc: Robert D Anderson > > > > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > > > > > > > When we automate the process of sending topics out for > > > > translation, we > > > > > ask the translators to change the xml:lang attribute to the > > correct > > > > > languages, which in the CMS environment enables the topics to > be > > > > > synchronized correctly with the source language topics. It's > very > > > > > important that the attribute be placed on every topic > correctly. > > > > > > > > > > When topics are changed, we can are able to send only those > > > > topics for > > > > > retranslation or, in some cases, only the individual > > > > strings that have > > > > > been changed. All of these controls helps to reduce > > > > translation costs. > > > > > > > > > > The xml:lang attribute at the map level will not have the > correct > > > > > effect. The translators do not see the maps. > > > > > > > > > > JoAnn > > > > > > > > > > JoAnn Hackos PhD > > > > > President > > > > > Comtech Services, Inc. > > > > > joann.hackos@comtech-serv.com > > > > > Skype joannhackos > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] > > > > > Sent: Wednesday, August 04, 2010 9:09 AM > > > > > To: Chris Nitchie; Su-Laine Yeo; Helfinstine, David; DITA TC > > > > > Cc: Robert D Anderson > > > > > Subject: RE: [dita] Cascading of xml:lang attribute > > > > > > > > > > If the value of xml:lang cascades to a topic that has no value > > set, > > > > > then it would be mandatory (a strongly advised best practice?) > > for > > > > > someone or something to set xml:lang on every topic to > > > > avoid problems. > > > > > But if we expect every topic to have xml:lang set, then there's > > no > > > > > reason to have xml:lang cascade. By that logic, it should > > > > be up to the > > > > > processor to decide what assumptions are appropriate when > > > > xml:lang is > > > > > not explicitly specified, and on what basis to make such > > > > assumptions. > > > > > > > > > > The descriptive/prescriptive dichotomy isn't apt. Any > > > > attribute value > > > > > specifies something descriptively about the content, and > > > > any attribute > > > > > value that isn't used for some kind of processing has no > > > > use case. The > > > > > value of xml:lang is no exception. > > > > > > > > > > /B > > > > > > > > > > > -----Original Message----- > > > > > > From: Chris Nitchie [mailto:cnitchie@ptc.com] > > > > > > Sent: Tuesday, August 03, 2010 8:50 PM > > > > > > To: Su-Laine Yeo; Helfinstine, David; DITA TC > > > > > > Cc: Robert D Anderson > > > > > > 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&g > > > > > > > roup_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/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > -- > > > > > > To unsubscribe from this mail list, you must leave the > > > > > OASIS TC that > > > > > > generates this mail. Follow this link to all your TCs in > > > > OASIS at: > > > > > > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgr > > > > > > oups.php > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > -- > > > > > To unsubscribe from this mail list, you must leave the > > > > OASIS TC that > > > > > generates this mail. Follow this link to all your TCs in OASIS > > at: > > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr > > > > > oups.php > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > -- > > -- > > > > To unsubscribe from this mail list, you must leave the OASIS > > > > TC that generates this mail. Follow this link to all your > > > > TCs in OASIS at: > > > > https://www.oasis- > > open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------- > -- > > > To unsubscribe from this mail list, you must leave the OASIS TC > that > > > generates this mail. Follow this link to all your TCs in OASIS at: > > > https://www.oasis- > > open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > ------------------------------------------------------------------- > -- > > > To unsubscribe from this mail list, you must leave the OASIS TC > that > > > generates this mail. Follow this link to all your TCs in OASIS at: > > > https://www.oasis- > > open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis- > open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]