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: Agenda for Monday 13 March meeting of the DITA Translation subcommittee

Hello All,

 
Agenda for Monday 13 March 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

Request for someone to take minutes as Gershon Joseph is unable to
attend.
 
Approve Minutes from 6 March 2006 (enclosed for those who are not TC
members)
 
<http://www.oasis-open.org/apps/org/workgroup/dita-translation/download.
php/16931/TranslationSCmeetingminutes060227.txt> 
 
New Business (according to preliminary proposals that have been
circulating)

Question: Are there any other proposals for the DITA 1.1 specification
than the three listed here.
 
    1) Entertain a proposal for inclusion of the dir attribute in the
DITA 1.1 specification.

    	Proposal: Add the DIR attribute to the DITA 1.1 specification as
a universal attribute and 	including the four values: LTR, RTL,
LRO, RLO, that are also included in the DocBook 	specification.
The default value will be LTR unless otherwise specified.

	Attached you will find the email trail on the DIR attribute as
of 10 March.
 
	2) Entertain a proposal for the possible inclusion of the ruby
attribute/element in the DITA 1.1 	specification.

	Proposal: Do not include the ruby attribute/element in the DITA
1.1 specification. Reconsider for 	the DITA 1.2 specification if a
need for this attribute is defined by the user community.
	
	Attached you will find some of the email trail on the ruby
attribute as of 10 March.

	Action: Wait for <keyref> to be fully designed, then evaluate it
for specialization to the W3c 	Ruby markup. Add a best practice for
those needing Ruby to specialize <keyref>. 


	3) Entertain a proposal for the clarification of xml:lang for
the DITA 1.1 specification.
	Proposal: Maintain the xml:lang attribute as currently specified
for DITA 1.1.

	Action: define best practices for xml editor vendors and
authoring organizations.

	Attached you will find some of the email trail on the xml:lang
attribute as of 12 March.

	4) Review Andrzej Zydron's workflow proposal (attached here)
 
 

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
--- Begin Message --- 
Looks like you have not used XMetaL's new BIDI release (I'm not sure if it's freely available yet). Maybe it's the only XML editor that works correctly (similar to Word)? I don't understand the argument that it's an output only issue. When working in documents with both English and Hebrew (we do lots of those), or both English and Arabic, not having the ability to control the direction makes XML useless to us. May as well work natively in MS Word, where we can control the direction correctly at input time.
 
We have lots of users who create multilingual documents who are currently investigating moving to XML. I'm not going to push the case for DITA to support the dir attribute, since it's probably only necessary in the ME, and we can continue using DocBook for these projects.
 
Adding dir to the DTD has very little overhead on the DTD side. How much work is required on the toolkit side remains to be seen (I need to test some samples, which I was planning to do once DITA 1.1 with the dir attribute was designed). If the group feels they would rather do without dir, so be it.
 
Best Regards,
Gershon

________________________________

From: Farwell, Kevin [mailto:Kevin.Farwell@lionbridge.com] 
Sent: Friday, March 10, 2006 3:48 AM
To: gershon@tech-tav.com; Robert D Anderson
Cc: bhertz@sdl.com; Bryan Schnabel; Charles Pau; Lieske, Christian; Dave A Schell; dita-translation@lists.oasis-open.org; dpooley@sdl.com; Felix Sasaki; Richard Ishida; Jennifer Linton; mambrose@sdl.com; patrickk@scriptware.nl; pcarey@lexmark.com; Reynolds, Peter; rfletcher@sdl.com; Munshi, Sukumar; tony.jewtushenko@productinnovator.com; Yves Savourel
Subject: RE: RE: [dita-translation] Draft proposal for dir attribute


Hi,
 
I would debate the definition of the word "support" when it comes to bi-directional text. I've attached some screen shots from three editors, Epic, XMetal, and Oxygen, as well as a screen shot of the PDF output generated from the XML. I picked a simple sample, and you can see no editor got it right. Epic and Oxygen got the Hebrew right and the English and period wrong and the whole sentence order wrong, but XMetal just reads the file logically. I also included a shot from MS Word, which is a very capable bi-directional DTP tool (although I would never recommend it as an XML tool), and it couldn't handle the XML either. A key feature in Word is the cursor direction setting, which makes typing a lot easier. Oxygen has a text direction indicator, but no a setting that can override the direction Unicode insists on. With those samples as a guide, I'd be wary of tagging the file according to what appears in an editor. In the interest of science, should you choose to repeat my experiments, all of these tests were done in a English OS. Perhaps the results would be different in a native OS, but I'm skeptical.
 
The next question is what "100% Unicode compliant" means. Many XML tools and text editors can display every Unicode character, so they might make the claim. Other tools can display a collection of RTL Unicode values as a word, but the sentence order is still LTR, so they might make a stronger claim. Still more, like Epic and Oxygen, get the sentence order of RTL text right, but can't do anything with LTR mixed in. That's better, but still not what I suspect you mean by 100%. Again, my opinion is that trusting an editor is pretty risky.
 
If we suppose there could be an editor really does represent all bi-di text as it should be, I'm not sure what would keep us from supposing the output tools do too. In that case, there would be no need for markup of any kind. Since no such editor exists, and no such output tool, we are stuck with requiring some kind of markup. However, there is no requirement on where that markup exists. It can be in the XML, which I think is not sufficient and can actually get in the way depending on what the target output is (and is different for Hebrew and Arabic scripts), or it can be integrated into the output process, in which case it is always tuned to the right output.
 
As a description of what I'm concerned with, I offer he_ppm.html. This file features an English phrase and that phrase translated into Hebrew. The first version of the translation has no corrective markup at all. The second and third translations show two different ways to add corrections. The first was added automatically and the second was added with much consternation by me. This represents my second try. The first had five spans, but I threw that all away and got it down to three. Looking at the representation of the string in Epic (epicppm.bmp), I can't imagine intuiting where the spans should go.
 
I don't think leaving direction tags off limits DITA at all. There are two levels of directional control, the direction and alignment of the whole document and the direction of characters inside paragraphs. Both are only a concern in the output. Unless there would be a case where an entire Hebrew or Arabic document should be output LTR, that setting can be added to the output with either a parameter passed at rendition time or a condition in the XSL that sets the document to RTL if the value of the language attribute calls for it. That control can also be managed conditionally on individual paragraphs, so there needn't be a control on the paragraph other than the language.
 
At the string level, controls must be applied according to the characters in the string. It is impossible to tell how the strings will come out until the output is viewed in its final form, so I think it builds inefficiency into the system to attempt to mark up the XML. I imagine an author tagging up a sentence, running HTML, viewing it, going back to the XML to make corrections, running HTML, viewing it, and so on. Then, once it's all straight, the boss comes in and says the output has to work in another browser with different CSS support and Unicode support (check the file in Safari or some other browser that isn't IE). The author is faced with making a copy of the file for each deliverable or overwriting the deliverable specific markup each time the file must be output. Neither is appealing.
 
One last point to help explain my position. I do a lot of work with bi-directional XML. Between me and other folks that sit around me, we have got maybe a couple of million words processed in the past few years. We don't use directional spans. I think it would be doing users a huge disservice to add tagging functionality that doesn't really translate to output functionality and translates to inefficient work. If the directional controls are added, they should be accompanied by a disclaimer that essentially says, "Your mileage may vary."
 
Kevin
--- End Message ---
--- Begin Message --- 
Hi all,

Here are the minutes from yesterday's meeting.

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



MEETING MINUTES -- 6 March 2006 -- DITA TRANSLATION SUBCOMMITTEE
(Minutes taken by Gershon Joseph <gershon@tech-tav.com>)

Date: Monday, 6 March 2006
Time: 08:00 - 09:00 PST

DITA Translation Subcommittee resources:
- SC Web site:
    http://www.oasis-open.org/apps/org/workgroup/dita-translation/index.php
- Mailing list: dita-translation@lists.oasis-open.org
- Non-OASIS members please email Gershon or Don and we'll post on
    your behalf

- Roll Call
    - Present - Robert Anderson, Don Day, Andrzej Zydron, Sandi
        Castle, Kevin Farwell, Gershon Joseph, Yves Savourel, Chris
        Wong, Nancy Harrison
    - Regrets - Rodolfo
 
- Review/approve minutes from previous meeting (27 February 2006)
    - http://www.oasis-open.org/apps/org/workgroup/dita-translation/download.php/16931/TranslationSCmeetingminutes060227.txt
    - JoAnn moves to accept the minutes, Don accepts.
 
- New Business (according to preliminary proposals that have been
  circulating)

  - revised inline elements table. Robert added some footnotes for
      clarification. (spectitle, specentry.)
    - Don moves to submit to TC and recommend this should be an
      appendix to the lang reference in the 1.1 spec.
    - doc will include later additions of all new 1.1 attributes.
    -- ACTION ITEM -- Robert to add new elements/attributes to the
      table.
 
- Entertain and discuss a proposal for inclusion of the dir
    attribute in the DITA specification
    - leaning towards adding dir as universal attribute with all 4 W3C
        values.
    - Don moves to accept dir attribute with values still to be
        determined via discussion this week, Robert seconds, no objections.
    -- ACTION ITEM -- Gershon to investigate and prepare more specific proposal.
 
- Entertain and discuss a proposal for clarification of xml:lang in
    the DITA specification with possible separation of the locale
    attribute
    - DISCUSSIONS...vendors requested us to separate locale from 
        lang; W3C are in early stages of working out what to do with 
	locale; we (DITA) don't want to jump ahead of the ITS spec...
    - Don moves to leave xml:locale out for now, and document best
        practices for the RFE3066. WE must point implementers to the most
        current values of the standards. Leave 1.1 spec of xml:lang as-is
        and clarify the language of the recommendation. Also remove
        English default.
    -- ACTION ITEM -- Gershon to revise recommendation
        statement for next week.
 
- Discuss a possible proposal for inclusion of the ruby
    attribute/element in the DITA specification
    - Don proposes not to include ruby for DITA in source, but to 
        discuss best practice to ensure annotation capability is 
	provided for in DITA and it could be interpreted into 
	ruby-like markup (i.e. keyref).
    - JoAnn - investigate a little further, but not applicable to 
        1,1, and we may have an alternative in the keyref. Add 
	recommendation for processors on how keyref may be 
	interpreted to ruby
    -- ACTION ITEM -- Gershon to research more and discuss with 
    Richard for decision next meeting.
 
--> meeting ended; next week we'll try to get to the next item after 
    discussing the proposal for DITA 1.1

- Review Andrzej Zydron's workflow proposal (attached here)
--- End Message ---
--- Begin Message --- 
Hi Gershon,

According to the W3C Localization tutorial 
(http://www.w3.org/International/tutorials/ruby/)

"Typically ruby is used in East Asian scripts to provide phonetic 
transcriptions of obscure characters, or characters that the reader is 
not expected to be familiar with. For example it is widely used in 
education materials and children’s texts. It is also occasionally used 
to convey information about the meaning of ideographic characters."

Ruby is only relevant to DITA if it is felt that there is a requirement 
for it in East Asian languages. Ruby is not compulsory for publishing 
Japanese or other East Asian text, it merely allows the 
author/translator to provide some indication regarding pronunciation 
which would otherwise not be obvious (something we would do using a 
phonetical rendition in parentheses) e.g. Zydroń (pron. Ziddrogne).

I have personally been involved with publishing technical documentation 
into Japanese for over 15 years and have yet to come across a situation 
where the lack of Ruby support has been a problem.

Therefore, IMHO, Ruby is not a pressing need regarding DITA 1.1. It is 
worth considering it, with regard to providing enhanced support for East 
Asian scripts in DITA 1.2.

Best Regards,

AZ

Gershon L Joseph wrote:
> Hi all,
> 
> Following up to our discussions at last Monday's Translation subcommittee
> discussions about Ruby:
> 
> - Discuss a possible proposal for inclusion of the ruby
>     attribute/element in the DITA specification
>     - Don proposes not to include ruby for DITA in source, but to 
>         discuss best practice to ensure annotation capability is 
> 	provided for in DITA and it could be interpreted into 
> 	ruby-like markup (i.e. keyref).
>     - JoAnn - investigate a little further, but not applicable to 
>         1,1, and we may have an alternative in the keyref. Add 
> 	recommendation for processors on how keyref may be 
> 	interpreted to ruby
>     -- ACTION ITEM -- Gershon to research more and discuss with 
>     Richard for decision next meeting.
> 
> After a little more thinking, I feel we should accept JoAnn's move to remove
> Ruby from DITA 1.1. After 1.1 (or maybe even after 1.2), we could
> investigate whether the keyref attribute could be used to hold Ruby data
> that would be output to the appropriate Ruby markup at publishing time.
> Personally, I think we should wait for users to request Ruby support before
> we consider any further work (documenting best practices, changing the spec,
> or anything else) related to Ruby. I feel our efforts should rather be spent
> on 1.1 items at this time.
> 
> 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
> 
> 
> 
> ---------------------------------------------------------------------------------------------------
> Text inserted by Panda Platinum 2005 Internet Security:
> 
>  This message has NOT been classified as spam. If it is unsolicited mail (spam), click on the following link to reclassify it: http://127.0.0.1:6083/Panda?ID=pav_47689&SPAM=true
> ---------------------------------------------------------------------------------------------------
> 
> 


-- 


email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
may not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.
--- End Message ---

DITA and xml-tm workflow.pdf

--- Begin Message --- 
Hi Kevin,

Gershon's suggestion is one good way of getting around your validation 
worries. Another way, if you want to do this via XML validation, is to 
create your own DITA extension DTD/Schema which provides a prescriptive 
list that conforms to your requirements. This is very easy and simple to 
do.

The main DITA standard though cannot limit the contents of xml:lang. As 
a standard its responsibilities are much broader and as such cannot 
redefine xml:lang as specified in the main XML 1.0 specification: 
http://www.w3.org/TR/2004/REC-xml-20040204/.

Best Regards,

AZ


> Hi Kevin,
> 
> If the authoring tool is set up correctly for the languages the particular
> project is to support, then the authoring tool can validate the xml:lang
> attribute at authoring time. If the authoring tool is not configured for
> this, then IMHO the organization doing the authoring is not using their XML
> tools correctly. All modern XML editors can easily be set up to validate an
> attribute value, and most also allow you to offer the author a list of
> values to choose from. Either way, the authoring tool is providing
> additional custom data validation beyond the rules of the DTD.
> 
> If you allow your authors to type in any xml:lang value that comes to mind,
> then you'll get the mess you talk about. If the person responsible for the
> tools sets the tools up correctly for the job at hand, you should never get
> invalid attribute values, even where the DTD does not specify a specific
> list of values.
> 
> 
> Best Regards,
> Gershon
> 
> ---
> Gershon L Joseph
> Member, OASIS DITA and DocBook Technical Committees
> Director of Technology and Single Sourcing
> Tech-Tav Documentation Ltd.
> 
> -----Original Message-----
> From: Farwell, Kevin [mailto:Kevin.Farwell@lionbridge.com] 
> Sent: Friday, March 10, 2006 6:37 PM
> To: Andrzej Zydron
> Cc: gershon@tech-tav.com; Felix Sasaki; Robert D Anderson; bhertz@sdl.com;
> Bryan Schnabel; Charles Pau; Lieske, Christian; Dave A Schell;
> dita-translation@lists.oasis-open.org; dpooley@sdl.com; Richard Ishida;
> Jennifer Linton; mambrose@sdl.com; patrickk@scriptware.nl;
> pcarey@lexmark.com; Reynolds, Peter; rfletcher@sdl.com; Munshi, Sukumar;
> tony.jewtushenko@productinnovator.com; Yves Savourel
> Subject: RE: [dita-translation] Changes to documentation of xml:lang and
> translate attributes
> 
> Hi,
> 
> I think we're talking about two different things. Every time I bring up a
> problem of whether a valid XML file is correct, I am told my premise is
> incorrect because the attribute values I suggest do not follow rules
> external to the tools that validate the file. I'm not questioning the work
> leading up to what constitutes a locale code in an XML file. I'm questioning
> a plan that relies on authors to have read and understood that work. I agree
> that the absurd locale codes I've offered are not correct, but I contend
> once again that if you type them into the value of the xml:lang attribute
> your file will be valid (and incorrect).
> 
> What I'm trying to get to is whether it's a good idea to have valid xml
> files that can contain incorrect information and then rely on an output
> process to find those incorrect values. I say it isn't. 
> 
> Should you think my suggestion that authors might use incorrect values is
> not reasonable, I assure you I'm not just dreaming it up. Do a survey of
> your clients or colleagues about various language or country codes.
> Some will guess, and some will have such confidence in their guess they will
> not consider looking it up. 
> 
> Kevin  
> 
> -----Original Message-----
> From: Andrzej Zydron [mailto:azydron@xml-intl.com]
> Sent: Friday, March 10, 2006 7:22 AM
> To: Farwell, Kevin
> Cc: gershon@tech-tav.com; Felix Sasaki; Robert D Anderson; bhertz@sdl.com;
> Bryan Schnabel; Charles Pau; Lieske, Christian; Dave A Schell;
> dita-translation@lists.oasis-open.org; dpooley@sdl.com; Richard Ishida;
> Jennifer Linton; mambrose@sdl.com; patrickk@scriptware.nl;
> pcarey@lexmark.com; Reynolds, Peter; rfletcher@sdl.com; Munshi, Sukumar;
> tony.jewtushenko@productinnovator.com; Yves Savourel
> Subject: Re: [dita-translation] Changes to documentation of xml:lang and
> translate attributes
> 
> Hi Kevin,
> 
> The reason why we should not have a prescriptive list for xml:lang, is the
> same one that inclined the W3C to do the same, or for that matter RFC 3066
> itself. RFC 3066 is designed as an open ended notation based on ISO 3166 and
> ISO 639. Why doesn't RFC 3066 provide a defined list of values? Because it
> would be too restrictive. There is little point in trying to outsmart the
> W3C or IANA. They have been through this process many, many times.
> 
> There is a clear distinction between what XML can do in terms of validation,
> and what externally referenced standards can do. XML 1.0 specifies that the
> value of xml:lang is governed by RFC 3066. Therefore
> "english_for_the_united_kingdom" is not valid.
> 
> In the end you have to provide your own validation for xml:lang based on RFC
> 3066. This is an XML fact of life.
> 
> Best Regards,
> 
> AZ
> 
> 
> Farwell, Kevin wrote:
> 
>>Hi,
>>
>>Let me clarify. I never said the rules are not clear. I said the 
>>method for enforcing the rules is not clear. While "en-uk" is not a 
>>valid locale according to the rules, it is completely valid according 
>>to the DTD. "english_for_the_united_kingdom" is also completely valid.
> 
> 
>>My point is not to fix the rules but to apply them. Incidentally, the 
>>list of allowed values in the DITA reference features lowercase 
>>country codes, which violates the capitalization rule listed below, 
>>for what it's worth.
>>
>>Using secondary tools to determine whether XML is correct seems risky 
>>to me. Validating a file, in that case, guarantees it's valid when 
>>tested against a content model but not necessarily that it is valid 
>>within a production environment. At very least, doesn't that create 
>>the potential for a false sense of security? Must every file be 
>>validated twice by two different methods? I would think that arriving 
>>at a valid file should mean that the file can go through the rest of 
>>the system with no further work.
>>
>>Kevin
>>
>>-----Original Message-----
>>From: Andrzej Zydron [mailto:azydron@xml-intl.com]
>>Sent: Wednesday, March 08, 2006 2:11 PM
>>To: gershon@tech-tav.com
>>Cc: Farwell, Kevin; 'Felix Sasaki'; 'Robert D Anderson'; 
>>bhertz@sdl.com; 'Bryan Schnabel'; 'Charles Pau'; 'Lieske, Christian'; 
>>'Dave A Schell'; dita-translation@lists.oasis-open.org;
>>dpooley@sdl.com; 'Richard Ishida'; 'Jennifer Linton'; 
>>mambrose@sdl.com; patrickk@scriptware.nl; pcarey@lexmark.com; 
>>Reynolds, Peter; rfletcher@sdl.com; Munshi, Sukumar;
> 
> tony.jewtushenko@productinnovator.com; 'Yves Savourel'
> 
>>Subject: Re: [dita-translation] Changes to documentation of xml:lang 
>>and translate attributes
>>
>>Hi Gershon,
>>
>>I agree with you. There is little point in setting out a proscriptive 
>>list. The implementation guidelines should state the contents of the 
>>xml:lang attribute must follow the rules of Extensible Markup Language
>>(XML) 1.0 (Third Edition) section 2.12, which mandates the use of IETF
> 
> 
>>RFC 3066. There should not be a need for a full proscriptive list as 
>>this would be too restrictive and inflexible. The rules for RFC 3066 
>>are well defined and not as free form as Kevin's email suggests.
>>
>>The value 'en-uk' is not a valid RFC 3066 value as per Kevin's example
> 
> 
>>for two reasons:
>>
>>1) 'uk' is not a valid ISO 3166 country code. 'GB' is the ISO 3166 
>>country code for Great Britain.
>>2) It is in lower case. Country codes must be in upper case.
>>
>>I can see no benefit in trying to 'better' the XML standard itself. 
>>The only weakness in RFC 3066 is the inability to add script 
>>information to the locale as well as regional or variant settings.
>>This is not going to be a problem for DITA in the near term. These 
>>issues are being addressed in RFC 3066bis, which is still in draft 
>>form. RFC 3066bis is backwards compatible with RFC 3066 and should not
> 
> 
>>cause a problem for any DITA 1.1 implementation anyway.
>>
>>Best Regards,
>>
>>AZ
>>
>>Gershon L Joseph wrote:
>>
>>
>>>If we hard-code it in the DTD, we'll have a hard time keeping the set 
>>>of allowable values up-to-date. Also, I've yet to find an accurate 
>>>fully up-to-date list of values on the Web that's not draft or 
>>>incomplete. I think it should be up to the implementation to ensure 
>>>the value entered is valid, or to offer the user a list of options 
>>>customized to the user's needs. I suspect offering a list of about 100
>>
>>
>>>values will confuse the user almost as much as leaving them to
>>
>>research it themselves.
>>
>>
>>>I don't mind adding a link in the spec documentation to an accurate 
>>>list that's always going to be kept updated. I have not found such a 
>>>list (I'm sure it exists, but I could find anything valuable via
>>
>>Google).
>>
>>
>>>What do others think?
>>>
>>>
>>>Best Regards,
>>>Gershon
>>>
>>>-----Original Message-----
>>>From: Farwell, Kevin [mailto:Kevin.Farwell@lionbridge.com]
>>>Sent: Wednesday, March 08, 2006 6:58 PM
>>>To: gershon@tech-tav.com; Felix Sasaki; Robert D Anderson
>>>Cc: bhertz@sdl.com; Bryan Schnabel; Charles Pau; Lieske, Christian; 
>>>Dave A Schell; dita-translation@lists.oasis-open.org; dpooley@sdl.com;
>>
>>
>>>Richard Ishida; Jennifer Linton; mambrose@sdl.com; 
>>>patrickk@scriptware.nl; pcarey@lexmark.com; Reynolds, Peter; 
>>>rfletcher@sdl.com; Munshi, Sukumar; 
>>>tony.jewtushenko@productinnovator.com; Yves Savourel
>>>Subject: RE: [dita-translation] Changes to documentation of xml:lang 
>>>and translate attributes
>>>
>>>Hi,
>>>
>>>I have a question about the values of the xml:lang attribute. With 
>>>phrases like "The allowed xml:lang values..." from the DITA reference 
>>>and "This attribute must be set to a language identifier, as
>>
>>defined..."
>>
>>>from the email below, I don't understand why the values aren't set in 
>>
>>>the DTD and the users aren't given a list to pick from instead of a 
>>>set of rules to follow. As an NMTOKEN, the value of the xml:lang 
>>>attribute can be anything the user desires as still be valid. If 
>>>something must be enforced, why leave it to users to enforce it? Why 
>>>doesn't the content model enforce it?
>>>
>>>Confusion surrounding the locale codes is fairly easy to understand. 
>>>The textual description runs country-language, but the symbol runs 
>>>language-country. If a user is trying to remember the symbol for UK 
>>>English, gb-en is as likely as en-gb, and even if they remember the 
>>>country comes first, why wouldn't UK English be en-uk? Latvian is 
>>>lv-lv, so why isn't Japanese ja-ja or jp-jp? If what's "allowed"
>>>"must" be in the attribute value, why leave it to chance or leave it 
>>>up to users doing research (which, in my opinion, are the same thing)?
>>>
>>>Kevin
>>>
>>>-----Original Message-----
>>>From: Gershon L Joseph [mailto:gershon@tech-tav.com]
>>>Sent: Wednesday, March 08, 2006 8:38 AM
>>>To: 'Felix Sasaki'; 'Robert D Anderson'
>>>Cc: bhertz@sdl.com; 'Bryan Schnabel'; 'Charles Pau'; 'Lieske, 
>>>Christian'; 'Dave A Schell'; dita-translation@lists.oasis-open.org;
>>>dpooley@sdl.com; 'Richard Ishida'; 'Jennifer Linton'; 
>>>mambrose@sdl.com; patrickk@scriptware.nl; pcarey@lexmark.com; 
>>>Reynolds, Peter; rfletcher@sdl.com; Munshi, Sukumar; 
>>>tony.jewtushenko@productinnovator.com;
>>>'Yves Savourel'
>>>Subject: RE: [dita-translation] Changes to documentation of xml:lang 
>>>and translate attributes
>>>
>>>Thank you all for your input. I'm replying to all comments in a single
>>
>>
>>>email to make it easier to follow this thread and where we're going...
>>>
>>>Here are new proposals for the two attributes based on all the 
>>>feedback I've received to-date, as well as our discussions during
>>
>>Monday's SC meeting.
>>
>>
>>>My previous proposal kept the original descriptions in the current 
>>>spec as much as possible, and I'm glad I received the reactions I did
>>
>>(e.g.
>>
>>
>>>English being the default language -- I felt uneasy about that one
>>
>>too).
>>
>>
>>>I took the default values from the spec, which I now see confused 
>>>everyone; I've changed them to reflect their usage.
>>>
>>>PROPOSAL FOR translate ATTRIBUTE:
>>>
>>>Name: translate
>>>
>>>Description: Indicates whether the content of the element should be 
>>>translated or not. The translate attribute setting applies to the 
>>>element on which it is set, and is inherited by all child elements 
>>>that do not specify the translate attribute. The translate attribute 
>>>does not indicate whether attribute values of the element and its 
>>>children should be translated; attribute values should never be 
>>>translated. If this attribute is not specified on the document 
>>>element, then processors must assume translate="yes".
>>>
>>>Data Type: yes | no
>>>
>>>Default Value: Not set
>>>
>>>Required: #IMPLIED
>>>
>>>
>>>PROPOSAL FOR xml:lang ATTRIBUTE:
>>>
>>>Name: xml:lang
>>>
>>>Description: Specifies the language and 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
>>>
>>>
>>>
>>>----------------------------------------------------------------------
>>>----------------------------- Text inserted by Panda Platinum 2005 
>>>Internet Security:
>>>
>>>This message has NOT been classified as spam. If it is unsolicited 
>>>mail (spam), click on the following link to reclassify it:
>>>http://127.0.0.1:6083/Panda?ID=pav_47530&SPAM=true
>>>----------------------------------------------------------------------
>>>-----------------------------
>>>
>>>
>>
>>
>>
> 
> 


-- 


email - azydron@xml-intl.com
smail - c/o Mr. A.Zydron
	PO Box 2167
         Gerrards Cross
         Bucks SL9 8XF
	United Kingdom
Mobile +(44) 7966 477 181
FAX    +(44) 1753 480 465
www - http://www.xml-intl.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
may not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version. Unless
explicitly stated otherwise this message is provided for informational
purposes only and should not be construed as a solicitation or offer.
--- End Message ---

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