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


Looks good. Thanks! 

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


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