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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita-translation message

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


Subject: DITA Subcommittee Agenda -- 10 April 2006


 Hello All,

Agenda for Monday 10 April 2006
11:00 am - 12:00 am Eastern Standard Team (-5 GMT)
DITA Technical Committtee teleconference 
USA Toll Free Number: 866-566-4838 
USA Toll Number: +1-210-280-1707 
PASSCODE: 185771


Roll Call

Approve Minutes from 3 April 2006 (enclosed for those who are not TC
members)
http://www.oasis-open.org/apps/org/workgroup/dita-translation/

This link goes to the subcommittee home page rather than directly to the
minutes. Please link to the minutes yourselves.

I have attached a Word document with the minutes. It also contains the
full text of the April 3 proposals. The attached email contains the text
of the xml:lang proposal submitted to the TC on April 4.

In addition, I have attached Paul Prescod's statement of the behavior of
conref in terms of the xml:lang. Please review to understand the
proposed behavior of a conref-ed text.

Action Items:
Discussion of the dir attribute proposal (Gershon Joseph, Kevin Farwell,
Richard Ischida)
Use cases for the xml:lang attribute (submitted by JoAnn Hackos) Closed


New Business

1) Gershon will review the current status of the xml:lang proposal based
on the email discussions that have occurred since the TC approved the
proposal last week.

I believe that everyone has been copies on the emails, although some
have circulated among TC members. 

Below are the links to last week's proposals. I hope everyone already
has this information from last week's agenda. Continued discussion of
dir during the week.

Gershon will send everyone the latest copy of the xml:lang
specification.

2)Discuss best practices for the dir attribute based on input from
Gershon, Kevin, and Richard.

3) Begin a discussion of the best practices surrounding inline elements.
I hope that Robert Anderson can start us off with a recommended course
of action.
 
 
 

JoAnn 

JoAnn T. Hackos, PhD 
President 
Comtech Services, Inc. 
710 Kipling Street, Suite 400 
Denver, CO 80215 
303-232-7586 
joann.hackos@comtech-serv.com 
http://www.comtech-serv.com <http://www.comtech-serv.com/>  
Skype joannhackos


DITA SC Meeting Minutes - 3 April 2006.doc

--- Begin Message ---
Hi all,

Here is the final xml:lang proposal, edited to remove references to Unicode.

Best Regards,
Gershon

---
Gershon L Joseph
Member, OASIS DITA and DocBook Technical Committees
Director of Technology and Single Sourcing
Tech-Tav Documentation Ltd.
office: +972-8-974-1569
mobile: +972-57-314-1170
http://www.tech-tav.com


Title: Proposal for xml:lang Attribute

Proposal for xml:lang Attribute

Gershon Joseph


Name

xml:lang

Description

Specifies the language (and optionally the locale) of the element content. The intent declared with xml:lang is considered to apply to all attributes and content of the element where it is specified, unless overridden with an instance of xml:lang on another element within that content. When no xml:lang value is supplied, the processor should assume a default value.

This attribute must be set to a language identifier, as defined by IETF RFC 3066 (http://www.ietf.org/rfc/rfc3066.txt) or successor.

Data Type

NMTOKEN

Default Value

Not set

Required

#IMPLIED

Recommended Usage

For a DITA document that contains a single language, the highest level element containing content should always set the xml:lang attribute to the language (and optionally the locale) that applies to the document. Since the dita element does not support the xml:lang element, the highest level element that should set the xml:lang attribute is the topic element (or derivatives at the same level).

For a DITA document that contains more than one language, the highest level element should always set the xml:lang attribute to the primary language (and optionally the locale) that applies to the document. Wherever an alternate language occurs in the document, the element containing the text or structure in the alternate language should set the xml:lang attribute appropriately. The above way of overriding the default document language applies to both block and inline elements that use the alternate language.

Using markup to identify language is strongly recommended to make the document as portable as possible. In addition, the marked-up document can be read and understood by humans. Finally, when updating the document, the boundaries of each language are clear, which makes it much easier for the author to update the document.

The xml:lang attribute can be specified on the map element. The expected language inheritance behavior on the map is similar to that on the topic. That is, the primary language for the map should be set on the map element (or assumed by the application if not explicitly set), and should remain in effect for all children unless a child specifies a different value for xml:lang.

In the case of a contradiction between the xml:lang value set on the map and the xml:lang value set on the topic, the setting on the topic overrides.

Use Case

Technical manuals frequently contain entire topics that are in languages different from the primary source languages of most of the topics. A manual in English, for example, may contain warnings that are in multiple languages, or have multiple topics of warnings each in individual languages. A manual may also contain regulatory notices as individual topics in different languages.

Therefore, a map might reference topics that are written in more than one language. In this case, each topic (or section within the topic) would use the xml:lang attribute to specify the language of the topic or section. Processors identify the language of each topic or section by the xml:lang attribute set in the topic file. However, it may be useful to specify the xml:lang attribute at the map level (on topicref elements) to help identify the language of each topic the map refers to.

Note to Vendors/Implementors

The recommended practice is to identify every change in language via XML markup. When reading XML markup that embeds scripts of different languages, the embedded languages should be indicated via markup when the document is saved.

Applications should ensure every highest level topic element and the root map element explicitly assign the xml:lang attribute.

--- End Message ---
--- Begin Message ---
I thought I would help Michael out. ;)

=====

Definition: Post DITA-Processing Infoset (PDPI)

A Post-DITA Processing Infoset is an infoset that results from the
application of DITA conref, conditional processing and metadata rules to
a map or topic.

Definition: Post DITA-Conref Element (PDCE)

A Post DITA-Conref Element is an element infoset item derived from an
XML element information item("the originating element") in an input
document information item.

Definition: Language Property

An DITA processor should augment the originating infoset and the PDPI by
adding the language property to each element information item. The value
of this property is the normalized value of the xml:lang attribute
appearing on that element if one exists, with xml:lang="" resulting in
no value, otherwise it is the value of the language property of the
element's parent element if one exists, otherwise the property has no
value. (this is ripped off from http://www.w3.org/TR/xinclude/#language)

Rule: Language of PDCEs

The language property associated with a PDCE infoset item is the same as
the language property that is associated with the originating element in
the input document. The original language property is assigned according
to normal XML rules. If the origin has no language property then the
language property should be set to the empty string.

In the vernacular, this means that a conref processor must copy the
xml:lang attribute attached to a referent element or to its most direct
ancestor containing an xml:lang attribute. If there is no such attribute
then the processor should copy the empty string.

=====

As a purely philosophical point, we define the mapping from originating
elements to PDCEs and can do whatever we want in that transformation.

In addition, I notice that the idea of scoping xml:lang elements is not
defined in either XML or the infoset proposal. 

 Paul Prescod


--- End Message ---


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