[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Cascading of xml:lang attribute
> The default value of the processor may be fixed, or it may be ...
The challenge with a list is being absolutely certain that it is covers everything that imaginative implementers might come up with.
> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Thursday, August 26, 2010 9:11 PM
> 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 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_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]