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


I'm mostly okay with the wording, but we have to be very
careful about our use of terminology that we don't make
things more confusing.  Comments below.

> -----Original Message-----
> From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> Sent: Thursday, 2010 August 26 20:11
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Cascading of xml:lang attribute
> 
> In the TC meeting a couple of weeks ago I think we came to consensus on
> the following:
> 1) @xml:lang does not cascade from maps to topics
> 2) It is reasonable for a processor to set its default language for
> processing by looking at the @xml:lang value on the primary map file
> 
> Currently the spec only mentions #1, so people who unlike us have not
> spent 10 hours combing over difference between cascading and setting a
> default may be confused by a processor which implements the behaviour
> described in #2.
> 
> Page 77-89 of the PDF file in CD03 currently says:
> 
> "The @xml:lang attribute specifies the language (and optionally the
> locale) of the element content. The @xml:lang
> attribute applies to all attributes and content of the element where it
> is specified, unless it is overridden with @xml:lang
> on another element within that content. When no @xml:lang attribute is
> specified, the processor should assume a
> default value."
> 
> I propose changing this to:
> 
> "The @xml:lang attribute specifies the language (and optionally the
> locale) of the element content. The @xml:lang
> attribute applies to all attributes and content of the element where it
> is specified, unless it is overridden with @xml:lang on another 
> element within that content. If no @xml:lang attribute is specified in

You cannot use the word "specified" here.  An "attribute specification"
is a specific term that implies the presence of an attribute assignment
in a particular start tag (and does not account for a possible default
being assigned by the schema).  Furthermore, "specified in" doesn't make
sense, especially "specified in a ... map" which could be taken to
be talking about any assignment anywhere within a map document.

It's hard to be precise short of using infoset terminology
(which will admittedly confuse everyone except a few geeks),
so the best I can do is suggest something informal like:

 If the @xml:lang attribute on the document (outermost) element
 of a map or top-level topic has no value, the processor...

paul

> a given map or top-level topic, the processor should assume a
> default value. The default value of the processor may be fixed, or it
> may be derived from a run-time parameter, configuration file, other
> setting, or from the content itself, such as the @xml:lang attribute on
> the primary map file."
> 
> Su-Laine
> 
> Su-Laine Yeo
> Solutions Consultant
> JustSystems Canada, Inc.
> Office: 778-327-6356
> syeo@justsystems.com
> www.justsystems.com
> XMetaL Community Forums: http://forums.xmetal.com/
> 
> 
> 
> -----Original Message-----
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Monday, August 09, 2010 7:24 AM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Cascading of xml:lang attribute
> 
> The xml:lang attribute doesn't--and shouldn't--cascade
> (for a variety of reasons discussed in the past).
> 
> We shouldn't be saying anything about processor defaults
> in the standard other than to say that they are implementation
> dependent.
> 
> Since generated text is usually going to be in the target
> language and generated text is usually defined in a stylesheet,
> one reasonable processor default is to do something based
> on the stylesheet being used.
> 
> Another reasonable processor default is to use the system
> locale value.
> 
> I think all Dave was saying was that yet another possible
> processor default is to do something based on some value
> in the primary map.  But I believe he was only making the
> point that there are multiple ways by which a processor
> could reasonably determine an implementation dependent
> default in the unrecommended case that a topic is missing
> an xml:lang assignment.
> 
> We do not want to be suggesting that cascading xml:lang
> values is the correct--or even reasonable--thing to do.
> 
> paul
> 
> > -----Original Message-----
> > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > Sent: Monday, 2010 August 09 9:11
> > To: Su-Laine Yeo
> > Cc: dita@lists.oasis-open.org
> > Subject: RE: [dita] Cascading of xml:lang attribute
> >
> > Hi Su-Laine,
> >
> > > David H. said that he'd be OK with having a processor pick up the
> > > xml:lang on the map and using it to set the processor default. This
> > > seems to me to be functionally equivalent to having the xml:lang
> > > attribute cascade.
> >
> > I don't think that is actually functionally equivalent - at least, if
> I
> > read David's words very literally. I think David is suggesting that
> the
> > xml:lang attribute on the primary map element itself - that map being
> > the
> > starting point of this information set - could establish a default
> for
> > the
> > entire information set.
> >
> > If an attribute cascades, then it may be reset at different levels in
> > the
> > map. If one branch is in English, and one branch in Russian,
> different
> > values would cascade from that point, and those branches could
> override
> > the
> > original value set at the map level.
> >
> > David - am I right in seeing a distinction between your suggestion
> and
> > this
> > interpretation? Were you suggesting that the default come from the
> map
> > element in the main map, the map element in any referenced map, or
> (as
> > with
> > other cascading attributes) any level of any map?
> >
> > > I propose changing this to:
> > > "Processors may treat the @xml:lang value as cascading from one map
> > > to another or from a map to a topic. An @xml:lang value specified
> in
> > > a map may be used if @xml:lang is not defined in child maps or
> > > topics. However, an @xml:lang value specified in a map must never
> > > override explicit @xml:lang values specified in other maps or in
> > topics.
> > "
> >
> > I'm not entirely comfortable with that, because to me it reads
> exactly
> > like
> > our other definitions of cascade, except that it's a may instead of a
> > must.
> > If we do end up declaring this type of cascade, I'd prefer to simply
> > state
> > that it may cascade, rather than redefining cascade behavior.
> >
> > Personally I'm more comfortable with David's suggestion (as I read
> it),
> > which seems closer to the spec intent. The spec currently refers to a
> > processor default, which to me implies a single value for all topics
> > that
> > do not specify xml:lang. I think it's logical to get that default
> from
> > the
> > root element of the map, just as it's logical to get the default from
> a
> > setting in the processing software. However, if the value cascades,
> we
> > may
> > end up with several defaults, depending on where in the map a topic
> is
> > referenced.
> >
> > Robert D Anderson
> > IBM Authoring Tools Development
> > Chief Architect, DITA Open Toolkit
> >
> > "Su-Laine Yeo" <su-laine.yeo@justsystems.com> wrote on 08/06/2010
> > 03:45:09
> > PM:
> >
> > > "Su-Laine Yeo" <su-laine.yeo@justsystems.com>
> > > 08/06/2010 03:45 PM
> > >
> > > To
> > >
> > > <dita@lists.oasis-open.org>
> > >
> > > cc
> > >
> > > Subject
> > >
> > > RE: [dita] Cascading of xml:lang attribute
> >
> > >
> > > Hi everyone,
> > >
> > > I went back to the DITA users who had told me they didn't want to
> > > have to put xml:lang on every topic, and they more or less agreed
> > > that putting xml:lang on every topic would not be a huge burden. So
> > > I believe we have consensus, which we didn't have before, on the
> > > following points:
> > > - Setting xml:lang on each topic will assist in reuse across maps,
> > > faceted search, and possibly authoring, and is strongly
> recommended.
> > > - Setting xml:lang on each topic is not too much of a burden for
> > adopters.
> > >
> > > Yay :)
> > >
> > > However:
> > > - Accidents happen. If a team tries to put xml:lang on every topic
> > > but fails in 0.1% of cases, that is approximately one error every
> > > 500-1000 pages.
> > > - Some processors treat xml:lang as cascading. With the current
> > > wording of the draft 1.2 spec, these processors would be required
> to
> > > stop this behavior.
> > > - There are teams with legacy content that does not have xml:lang
> on
> > > every topic, because they produce single-language deliverables and
> > > their processors have thus far picked it up from the map.
> > >
> > > A good point has been raised that the map might not have the
> correct
> > > xml:lang for describing the language of a topic that doesn't itself
> > > include xml:lang. However if the xml:lang in the map is different
> > > from the processor's default, which is more likely to correctly
> > > describe the language of the topic: the map, or the processor
> > > default?  The processor default is more likely to be correct if we
> > > assume that a topic that does not declare xml:lang is likely to be
> > > in English. However in an environment where people are making an
> > > effort to declare xml:lang in all topics including English ones, I
> > > would think that accidental omission of xml:lang would be equally
> > > likely for all languages.
> > >
> > > David H. said that he'd be OK with having a processor pick up the
> > > xml:lang on the map and using it to set the processor default. This
> > > seems to me to be functionally equivalent to having the xml:lang
> > > attribute cascade.
> > >
> > > The draft 1.2 spec currently says:
> > > "The @xml:lang value does not cascade from one map to another or
> > > from a map to a topic, and an @xml:lang value specified in a map
> > > does not override @xml:lang values specified in other maps or in
> > topics.
> > "
> > >
> > > I propose changing this to:
> > > "Processors may treat the @xml:lang value as cascading from one map
> > > to another or from a map to a topic. An @xml:lang value specified
> in
> > > a map may be used if @xml:lang is not defined in child maps or
> > > topics. However, an @xml:lang value specified in a map must never
> > > override explicit @xml:lang values specified in other maps or in
> > topics.
> > "
> > >
> > > How does that sound? BTW, the draft 1.2 spec already has plenty of
> > > wording to encourage people to set xml:lang on every topic.
> > >
> > > Su-Laine
> > >
> > >
> > > -----Original Message-----
> > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > > Sent: Thursday, August 05, 2010 12:47 PM
> > > To: bryan.s.schnabel@tektronix.com; dita@lists.oasis-open.org
> > > Subject: RE: [dita] Cascading of xml:lang attribute
> > >
> > > No, that's just what I had in mind, Bryan. Thanks! I've been aware
> > > of XLIFF for some time, without really looking into it.
> > >
> > > The DITA 1.2 spec talks about this issue at "2.1.3.9.1 The
> @xml:lang
> > > attribute". In particular, it says: "The @xml:lang value does not
> > > cascade from one map to another or from a map to a topic...." So a
> > > value of @xml:lang that is set in a map applies only to content
> that
> > > is immediately contained within the map, such as a title.
> > >
> > > Su-Laine's discussion looks at cascading, a top-down notion, from
> > > the other direction, bottom up. If @xml:lang is unspecified on some
> > > element (a note, in her example), look to the parent element, and
> do
> > > so recursively within the topic, but don't look outside the topic
> to
> > > the map. If no value is set anywhere in that walk up the DOM,
> assumea
> > default.
> > >
> > > I suppose a processor in fact might more efficiently work from the
> > > top down. When you encounter an element with @xml:lang set, push
> the
> > > current value onto a stack and use the new value on down the DOM
> > > from there until it's overridden or you exit the current branch
> > > dominated by the element that carried that value; whereupon take
> the
> > > earlier value back off the push-down stack. When you exit a topic,
> > > the last value that you can take off the stack is the system-set
> > default.
> > >
> > > (BTW, I just noticed a couple of typos in the section on use with
> > > @conref/@conkeyref: "If the reference element does not have an
> > > explicit value for the @xml:lang attribute, the effective value for
> > > its @xml:lang attribute is determined by using the standard
> > > @xml:lang inheritance from the referenced source.." Should be
> > > referenced element, and a single period. Do I have to go make a
> > > formal comment?)
> > >
> > > Su-Laine was reporting that users don't want the overhead of
> setting
> > > @xml:lang on every topic. The spec seems to suggest that this be
> > > automated in some way ("applications should") but also makes
> authors
> > > responsible ("authors are urged"):
> > >
> > > "Applications should ensure that every highest level topic element
> > > explicitly assigns the @xml:lang attribute. Authors are urged to
> set
> > > the @xml:lang attribute in the source language so that the
> > > translator may change it in the target language. Because some
> > > translation software does not permite translators to add elements,
> > > the absence of the @xml:lang element from the source language may
> > > result in higher administrative costs for translation." (I assume
> > > that "may change it in the target language" means "may change it in
> > > a copy (?) of the topic in which the content is translated to the
> > > target language")
> > >
> > > This gives one strong reason why users might want to bite the
> bullet
> > > and find a way to tag every topic. There is also the issue of
> > > sharing content to an environment where a different default
> > languageprevails.
> > >
> > >    /B
> > >
> > > > -----Original Message-----
> > > > From: bryan.s.schnabel@tektronix.com
> > > > [mailto:bryan.s.schnabel@tektronix.com]
> > > > Sent: Thursday, August 05, 2010 2:18 PM
> > > > To: Bruce Nevin (bnevin); dita@lists.oasis-open.org
> > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > >
> > > > Hi Bruce,
> > > >
> > > > Regarding your question:
> > > >
> > > > > can't you send fragments smaller than a topic for translation
> if
> > > > > that's all that has changed?
> > > >
> > > > I think that depends on your method of sending topics out for
> > > > translation. I see this as an absolute real-world
> > > > requirement. And I think a great way is to use the open
> > > > standard for translation, XLIFF, as part of your DITA process.
> > > >
> > > > I hope to resurrect the DITA Translation SC (under the DITA
> > > > Adoption TC) as soon as I can marshal the bandwidth. One of
> > > > the things members of that SC have talked about in the past
> > > > is evaluating the use of XLIFF as a best practice for
> > > > translating DITA. Using XLIFF as your Interchange File Format
> > > > when translating DITA topics enables exactly what you are
> > > > talking about.  The idea is that all of the topics referenced
> > > > by a given map would be transformed into an XLIFF file (XLIFF
> > > > is a preferred file format for translation providers and is
> > > > natively consumable by translation tools).
> > > >
> > > > So if fragments within the topic need to be translated the
> > > > XLIFF file can identify the strings that need to be
> > > > translated, and lock (but provide for context) the strings
> > > > that do not need translation. Here's a little sample:
> > > >
> > > > For this topic segment:
> > > > <section>
> > > >  <title>Electric Guitars</title>
> > > >  <p translate="no">Lester William Polsfuss aka Les Paul was
> > > >                    a pioneer of the development to the Solid
> > > >                    body Electic Guitar and modern recording
> > > >                    technologies.</p>
> > > >   <p translate="yes">Clarence Leonidas Fender, also known as
> > > >                    Leo Fender, moved the development of Electric
> > > >                    Guitars into the modern era, with smaller,
> more
> > > >                    portable solid body Electric Guitars.</p>
> > > > </section>
> > > >
> > > > This XLIFF segment would trigger the translator to translate
> > > > the second paragraph, but provide the first paragraph as a
> > > > locked, for context only topic fragment (note the @state
> > attribute):
> > > >
> > > > <group id="section-3">
> > > >  <trans-unit id="title-4">
> > > >   <source>Electric Guitars</source>
> > > >   <target state="needs-translation" xml:lang="de">Electric
> > > > Guitars</target>  </trans-unit>  <trans-unit id="p-5">
> > > >   <source>Lester William
> > > >    Polsfuss aka Les Paul was a pioneer of the development to the
> > Solid
> > > >    body Electic Guitar and modern recording technologies.
> > > >   </source>
> > > >   <target state="final" xml:lang="de">Lester William Polsfuss
> > > > alias Les Paul war ein
> > > >    Pionier der Entwicklung hin zur Solidbody-E-Gitarre und
> moderner
> > > >    Aufnahmetechniken.
> > > >   </target>
> > > > </trans-unit>
> > > > <trans-unit id="p-6">
> > > >  <source>Clarence Leonidas Fender, also known as Leo Fender,
> > > >   moved the development of Electric Guitars into the modern era,
> > with
> > > >   smaller, more portable solid body Electric
> > > > Guitars.</source>  <target state="needs-translation"
> > > > xml:lang="de">Clarence Leonidas Fender, also known as Leo Fender,
> > > >   moved the development of Electric Guitars into the modern era,
> > with
> > > >   smaller, more portable solid body Electric
> > > > Guitars.</target>  </trans-unit> </group>
> > > >
> > > > Hopefully this answer doesn't abstract too far beyond the
> > > > scenario you had in mind.
> > > >
> > > > - Bryan
> > > >
> > > > -----Original Message-----
> > > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > > > Sent: Thursday, August 05, 2010 8:56 AM
> > > > To: JoAnn Hackos; Chris Nitchie; Su-Laine Yeo; Helfinstine,
> > > > David; DITA TC
> > > > Cc: Robert D Anderson
> > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > >
> > > > I've not been directly involved with this, but can't you send
> > > > fragments smaller than a topic for translation if that's all
> > > > that has changed? Or are other means used to identify just
> > > > those parts that need the translator's attention?
> > > >
> > > > A topic may have different xml:lang values on different
> > > > fragments in it. Quotations, citations, and legal
> > > > requirements for bilingual environments come to mind.
> > > >
> > > >         /B
> > > >
> > > > > -----Original Message-----
> > > > > From: JoAnn Hackos [mailto:joann.hackos@comtech-serv.com]
> > > > > Sent: Wednesday, August 04, 2010 4:57 PM
> > > > > To: Bruce Nevin (bnevin); Chris Nitchie; Su-Laine Yeo;
> > Helfinstine,
> > > > > David; DITA TC
> > > > > Cc: Robert D Anderson
> > > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > > >
> > > > > When we automate the process of sending topics out for
> > > > translation, we
> > > > > ask the translators to change the xml:lang attribute to the
> > correct
> > > > > languages, which in the CMS environment enables the topics to
> be
> > > > > synchronized correctly with the source language topics. It's
> very
> > > > > important that the attribute be placed on every topic
> correctly.
> > > > >
> > > > > When topics are changed, we can are able to send only those
> > > > topics for
> > > > > retranslation or, in some cases, only the individual
> > > > strings that have
> > > > > been changed. All of these controls helps to reduce
> > > > translation costs.
> > > > >
> > > > > The xml:lang attribute at the map level will not have the
> correct
> > > > > effect. The translators do not see the maps.
> > > > >
> > > > > JoAnn
> > > > >
> > > > > JoAnn Hackos PhD
> > > > > President
> > > > > Comtech Services, Inc.
> > > > > joann.hackos@comtech-serv.com
> > > > > Skype joannhackos
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com]
> > > > > Sent: Wednesday, August 04, 2010 9:09 AM
> > > > > To: Chris Nitchie; Su-Laine Yeo; Helfinstine, David; DITA TC
> > > > > Cc: Robert D Anderson
> > > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > > >
> > > > > If the value of xml:lang cascades to a topic that has no value
> > set,
> > > > > then it would be mandatory (a strongly advised best practice?)
> > for
> > > > > someone or something to set xml:lang on every topic to
> > > > avoid problems.
> > > > > But if we expect every topic to have xml:lang set, then there's
> > no
> > > > > reason to have xml:lang cascade. By that logic, it should
> > > > be up to the
> > > > > processor to decide what assumptions are appropriate when
> > > > xml:lang is
> > > > > not explicitly specified, and on what basis to make such
> > > > assumptions.
> > > > >
> > > > > The descriptive/prescriptive dichotomy isn't apt. Any
> > > > attribute value
> > > > > specifies something descriptively about the content, and
> > > > any attribute
> > > > > value that isn't used for some kind of processing has no
> > > > use case. The
> > > > > value of xml:lang is no exception.
> > > > >
> > > > >       /B
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Chris Nitchie [mailto:cnitchie@ptc.com]
> > > > > > Sent: Tuesday, August 03, 2010 8:50 PM
> > > > > > To: Su-Laine Yeo; Helfinstine, David; DITA TC
> > > > > > Cc: Robert D Anderson
> > > > > > Subject: Re: [dita] Cascading of xml:lang attribute
> > > > > >
> > > > > > I would think in such a situation, where you have to
> > > > manage a large
> > > > > > number of languages, the only rational process is to mark
> > > > > each piece
> > > > > > of content with its language. The potential for assigning
> > > > the wrong
> > > > > > language to a piece of content via cascading, processor
> > > > > defaults, or
> > > > > > any other mechanism is higher in such cases than it is for
> the
> > > > > > customer with only one or two languages.
> > > > > >
> > > > > > If xml:lang cascaded from maps to topics when there's no
> > explicit
> > > > > > xml:lang on the topic, you'd wind up with content in the
> > > > > output marked
> > > > > > with the wrong language via cascading, and we would have to
> > > > > call that
> > > > > > valid DITA processing even though it's obviously incorrect.
> The
> > > > > > xml:lang and other locale-related attributes are different
> > > > > from other
> > > > > > cascading attributes because they are descriptive, not
> > > > > prescriptive;
> > > > > > they describe the content as it is, not metadata for how it
> > > > > should be
> > > > > > processed. Topics are in a language, and they're in that
> > > > > language no
> > > > > > matter what map references them, and no matter whether
> > > > they specify
> > > > > > xml:lang or not. Allowing a map - or anything else - to
> impose
> > a
> > > > > > language setting invites outcomes that are simply wrong.
> > > > I suspect,
> > > > > > but can't say for sure, that the language in the spec about
> > > > > processor
> > > > > > defaults is there because something has to establish a
> language
> > > > > > eventually, but it's not a very good substitute for
> > > > > assigning language
> > > > > > markers on your content.
> > > > > >
> > > > > > Chris
> > > > > >
> > > > > > On 8/3/10 6:07 PM, "Su-Laine Yeo"
> > > > > > <su-laine.yeo@justsystems.com> wrote:
> > > > > >
> > > > > > > Hi Dave,
> > > > > > >
> > > > > > > For teams which publish primarily in one language,
> > > > > setting a "good"
> > > > > > > default for the processor or putting xml:lang in the
> > > > > > template is not a big burden.
> > > > > > > However, consider a team that publishes in a dozen locales.
> > > > > > That team
> > > > > > > needs to set the locale parameter for the processor up
> > > > to a dozen
> > > > > > > times and get it right each time. You can automate builds
> > > > > to avoid
> > > > > > > having to set parameters over and over, but many adopters
> > > > > > do not have
> > > > > > > automated build processes, especially in the the early
> > > > > > stages of adoption.
> > > > > > >
> > > > > > > The question is whether processors should apply the
> > > > > xml:lang of the
> > > > > > > primary map *if that is the only place where xml:lang is
> > > > > > defined*. Why
> > > > > > > should the answer be no? I'm aware that changing the
> > > > > > xml:lang on a map
> > > > > > > or topic does not change the language of any other
> > > > sub-topics or
> > > > > > > sub-maps. However I donıt see how that (obvious) fact is
> > > > > > relevant to this question.
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Su-Laine
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Helfinstine, David [mailto:dhelfinstine@ptc.com]
> > > > > > > Sent: Tuesday, August 03, 2010 1:33 PM
> > > > > > > To: dita@lists.oasis-open.org
> > > > > > > Cc: Robert D Anderson; Su-Laine Yeo
> > > > > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > > > > >
> > > > > > > Greetings,
> > > > > > >
> > > > > > > The xml:lang should be considered an attribute set in each
> > > > > > document.
> > > > > > > There are other language type attributes like @dir and
> > > > > > @translate that
> > > > > > > are also document attributes. They also do not cascade from
> > > > > > map to map
> > > > > > > or map to topic or topic to sub topic, etc. These might be
> > > > > > important
> > > > > > > when processing so it would not necessarily be xml:lang
> > > > > alone that
> > > > > > > would need to be considered. As has been mentioned,
> > > > changing the
> > > > > > > xml:lang on a map or topic does not change the language of
> > > > > > any other sub-topics or sub-maps.
> > > > > > >
> > > > > > > The comments regarding setting the xml:lang in every
> > > > > > document can be
> > > > > > > overcome by setting a good processor default. If the
> > > > > > processor default
> > > > > > > in a French environment is ³fr² then it might be reasonable
> > > > > > that the
> > > > > > > processor default would be ³fr² unless a different xml:lang
> > is
> > > > > > > encountered in a map or topic. If however one of the French
> > > > > > documents
> > > > > > > were put into a different language map then the
> > > > processor default
> > > > > > > would probably be set to that language. The French author
> > > > > > would have
> > > > > > > to remember to put the xml:lang=²fr² in the French topic to
> > > > > > keep that
> > > > > > > from happening. Having the xml:lang=²fr² on the topic tag
> > would
> > > > > > > alleviate the problem in the first place. For those
> > > > users who use
> > > > > > > templates, it might be great to include in the template the
> > > > > > xml:lang already set to a decent default value. That way ­
> > > > > no worries!
> > > > > > >
> > > > > > > Before the DITA 1.2 the cascading of attributes was not
> > > > > > defined. There
> > > > > > > was talk of inheritance in DITA 1.1 and there was the one
> > > > > > reference to
> > > > > > > xml:lang regarding topicref and the actual topic. But as a
> > > > > > whole this
> > > > > > > topic was not defined rather than DITA 1.2 being a change
> > > > > > to the way they behaved.
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > > - Dave H.
> > > > > > >
> > > > > > > Dave Helfinstine
> > > > > > > DHelfinstine@ptc.com
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com]
> > > > > > > Sent: Tuesday, August 03, 2010 2:56 PM
> > > > > > > To: Robert D Anderson
> > > > > > > Cc: dita@lists.oasis-open.org
> > > > > > > Subject: RE: [dita] Cascading of xml:lang attribute
> > > > > > >
> > > > > > > Thanks Robert.
> > > > > > >
> > > > > > > We've received some quite strongly-worded comments from
> > > > > DITA users
> > > > > > > that having to set xml:lang on every single topic file
> > > > > would be an
> > > > > > > enormous hassle. For the case of a mostly-French document
> > > > > > that pulls
> > > > > > > in one English topic, it is reasonable to ask users to set
> > > > > > > xml:lang="fr" once on the map, and xml:lang="en" once on
> > > > > > the English
> > > > > > > topic. However I don't see why we would also require
> > > > users to set
> > > > > > > xml:lang="fr" on every French topic if they want those
> > > > > > topics to be processed in French.
> > > > > > >
> > > > > > > I see this as being a substantial change over the DITA 1.1
> > > > > > spec which
> > > > > > > adds work for users, and I can't see the practical benefit.
> > > > > > >
> > > > > > > Su-Laine
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Robert D Anderson [mailto:robander@us.ibm.com]
> > > > > > > Sent: Tuesday, August 03, 2010 12:33 PM
> > > > > > > To: Su-Laine Yeo
> > > > > > > Cc: dita@lists.oasis-open.org
> > > > > > > Subject: Re: [dita] Cascading of xml:lang attribute
> > > > > > >
> > > > > > > Trying to remember the discussion of this - I believe that
> > your
> > > > > > > reading of the 1.2 spec is correct.
> > > > > > >
> > > > > > > I think the idea was that the language is a property of the
> > > > > > document
> > > > > > > itself that travels with the document, and cannot be set or
> > > > > > reset from
> > > > > > > above. For example, if you have a map with all French
> > > > > > topics, but then
> > > > > > > reference an existing English topic somewhere else that
> > > > > > does not set
> > > > > > > xml:lang, the fact that you're referencing it from a French
> > > > > > map does
> > > > > > > not make the topic French. Following the spec's
> > > > recommendation to
> > > > > > > ensure xml:lang is on the root element of every document
> > > > > > helps bypass
> > > > > > > this issue and any resulting confusion.
> > > > > > >
> > > > > > > Robert D Anderson
> > > > > > > IBM Authoring Tools Development
> > > > > > > Chief Architect, DITA Open Toolkit
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >              "Su-Laine Yeo"
> > > > > > >              <su-laine.yeo@jus
> > > > > > >              tsystems.com>
> > > > > >             To
> > > > > > >
> > > > <dita@lists.oasis-open.org>
> > > > > > >              08/03/2010 03:11
> > > > > >             cc
> > > > > > >              PM
> > > > > > >
> > > > > >        Subject
> > > > > > >                                        [dita] Cascading
> > > > > of xml:lang
> > > > > > >                                        attribute
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi everyone,
> > > > > > >
> > > > > > >
> > > > > > > A bug report for the DITA Open Toolkit has raised some
> > > > interesting
> > > > > > > discussion:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> >
> https://sourceforge.net/tracker/?func=detail&atid=725074&aid=3038532&g
> > > > > > > roup_id=
> > > > > > > 132728
> > > > > > >
> > > > > > >
> > > > > > > Users need to know if they need to set the xml:lang
> > > > > > attribute only in
> > > > > > > their primary map, or for every topic. Developers of
> > > > > > processors need
> > > > > > > to know if processors should look at the map when deciding
> > > > > > what locale
> > > > > > > to use when displaying topics.
> > > > > > >
> > > > > > >
> > > > > > > Say you have a <note> element in a DITA topic that is
> > > > > > referenced by a
> > > > > > > DITA map. My reading of the DITA 1.1 spec is that language
> > > > > > should be
> > > > > > > determined as follows:
> > > > > > >
> > > > > > >
> > > > > > > 1) Get xml:lang from the <note> element. If xml:lang is
> > > > > not defined
> > > > > > > there, get it from the closest ancestor within the topic.
> > > > > > >
> > > > > > >
> > > > > > > 2) If xml:lang not defined in an ancestor of <note> within
> > > > > > the topic,
> > > > > > > get it from the <topicref> in the map.
> > > > > > >
> > > > > > >
> > > > > > > 3) If xml:lang not defined in the <topicref>, get it
> > > > from closest
> > > > > > > ancestor of the <topicref> within the map.
> > > > > > >
> > > > > > >
> > > > > > > 4) If xml:lang is not defined in any ancestor of the
> > > > > > <topicref> within
> > > > > > > the map, the processor should assume a default value.
> > > > > > >
> > > > > > >
> > > > > > > However, the draft DITA 1.2 spec contains the sentence ³The
> > > > > > @xml:lang
> > > > > > > value does not cascade from one map to another or from
> > > > a map to a
> > > > > > > topic², which seems to imply that the language should be
> > > > > > determined as follows:
> > > > > > >
> > > > > > >
> > > > > > > 1) Get xml:lang from the <note> element. If xml:lang is
> > > > > not defined
> > > > > > > there, get it from the closest ancestor within the topic.
> > > > > > >
> > > > > > >
> > > > > > > 2) If xml:lang not defined in an ancestor of <note> within
> > > > > > the topic,
> > > > > > > the processor should assume a default value.
> > > > > > >
> > > > > > >
> > > > > > > Is this the intention?
> > > > > > >
> > > > > > >
> > > > > > > Su-Laine
> > > > > > >
> > > > > > >
> > > > > > > Su-Laine Yeo
> > > > > > > Solutions Consultant
> > > > > > >
> > > > > > >
> > > > > > > JustSystems Canada, Inc.
> > > > > > > Office: 778-327-6356
> > > > > > > syeo@justsystems.com
> > > > > > >
> > > > > > >
> > > > > > > www.justsystems.com
> > > > > > >
> > > > > > >
> > > > > > > XMetaL Community Forums: http://forums.xmetal.com/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > > > > To unsubscribe from this mail list, you must leave the
> > > > > OASIS TC that
> > > > > > generates this mail.  Follow this link to all your TCs in
> > > > OASIS at:
> > > > > > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgr
> > > > > > oups.php
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > > > To unsubscribe from this mail list, you must leave the
> > > > OASIS TC that
> > > > > generates this mail.  Follow this link to all your TCs in OASIS
> > at:
> > > > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> > > > > oups.php
> > > > >
> > > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > > To unsubscribe from this mail list, you must leave the OASIS
> > > > TC that generates this mail.  Follow this link to all your
> > > > TCs in OASIS at:
> > > > https://www.oasis-
> > open.org/apps/org/workgroup/portal/my_workgroups.php
> > > >
> > > >
> > > >
> > > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe from this mail list, you must leave the OASIS TC
> that
> > > generates this mail.  Follow this link to all your TCs in OASIS at:
> > > https://www.oasis-
> > open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > > To unsubscribe from this mail list, you must leave the OASIS TC
> that
> > > generates this mail.  Follow this link to all your TCs in OASIS at:
> > > https://www.oasis-
> > open.org/apps/org/workgroup/portal/my_workgroups.php
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php



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