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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] 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



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