[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Cascading of xml:lang attribute
Looks good. Thanks! > -----Original Message----- > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] > Sent: Friday, August 27, 2010 7:21 PM > To: dita@lists.oasis-open.org > Subject: RE: [dita] Cascading of xml:lang attribute > > Good points Paul and Bruce. Latest version: > > "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 the > @xml:lang attribute on the document (outermost) element of a > map or of a top-level topic has no value, the processor > should assume a default value. The default value of the > processor may be either fixed, configurable, or derived from > the content itself, such as the @xml:lang attribute on the > primary map file. As the default value of a processor may be > fixed, it is strongly recommended that the @xml:lang > attribute be set on each map and top-level topic." > > Cheers, > Su-Laine > > -----Original Message----- > From: Grosso, Paul [mailto:pgrosso@ptc.com] > Sent: Friday, August 27, 2010 8:12 AM > To: dita@lists.oasis-open.org > 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 > > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]