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] Proposal: Domain for Japanese ruby markup ala HTML5


I would urge every member of the Subcommittee to comment on this proposal for Ruby. We need your experienced input.

Thank you,
JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
Joann.hackos@comtech-serv.com
303-232-7586



From: Don Day <donday@learningbywrote.com>
Date: Fri, 3 Feb 2012 10:32:11 -0600
To: JoAnn Hackos <joann.hackos@comtech-serv.com>
Cc: Eliot Kimber <ekimber@reallysi.com>, Rodolfo Raya <rmraya@maxprograms.com>, DITA TC <dita@lists.oasis-open.org>, "dita-translation@lists.oasis-open.org" <dita-translation@lists.oasis-open.org>
Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala HTML5

Thanks for this note from Tetsuya-san. I read each point of it as being in agreement that this proposal fits both current needs beyond Tech Pubs and aligns well with emerging requirements (as noted already by Nancy Harrison and other publishers to the Japanese market). Even point 4 is not an objection to the proposal--it is a statement about the problems that would arise in the lack of a standard recommendation. I appreciate his on-the-ground observations.

So the TC should also give consideration to Tetsuya-san's additional request for help with indexterm/index-sort-as glossary issues, but I believe that is separate from the inline Ruby itself. I suspect Eliot has something on that, but I'll ask him to submit it as a separate stage 1 proposal that we can vote to merge if in fact it becomes part of the same domain.
DITA and XML Consultant, Learning by Wrote
Co-Chair, OASIS DITA Technical Committee
"Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot

On 2/3/2012 10:01 AM, JoAnn Hackos wrote:
Hi,
I thinking Eliot, you may be stretching the circumstances and overstating
the case. Technical communications documents have been happily produced
from DITA into Japanese for years with no need for Ruby. Ruby is not
essential for Japanese documents at least with PDF etc. publications.

My understanding from Translation SC discussions before 1.2 is that Ruby
is chiefly used in schoolbooks. Now we have the note from Tetsuya Sekine
that mentions several important issues, possibly connected with ebooks.

I've copied his note here for those who did not see it.

I think it's really important that we not overstate or misrepresent the
case. 

I invite all members of the DITA Translation Subcommittee to comment in
this thread.


Thanks, JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
Joann.hackos@comtech-serv.com
303-232-7586

Hi all,

I was already discussed some of you, regarding Ruby functionality.
Only problem is that meeting is held during the time, I am not usually be
able to attend.

I discussed this issue with some colleagues in the field.

1.Currently, most of the users and information developers are not
necessary needing Ruby.
WHY: Because in Technical Communication, this does not have much impact on
current targeted audiences (Paper, PDF, Online Help)
HOWEVER: From the point of accessibility and computer-voiced instructions
feature especialy to the new deliverables such as smartphone, Ruby will be
needed.

2.Rendition part is already supported by tools like AH XSL Formatter, and
the same things applied with current HTML browser and its standard
(HTML5/CSS3).
3.DITA adaption for the commercial publishing definitely needs Ruby, so
this can contribute DITA to be adapted more in that field, in conjunction
with ePub.
4.It is not a good way to extend Ruby as the Japanese own specialized
implementation because this action is against open standard.
(From my own experiences, Japanese have a tendency to come up with own
domestic standard and make things complicated, not align with the standard)
PS
In addition to Ruby, we want to have the similar elements as used in
<indexterm>/<index-sort-as> for glossary entries, in order to sort from
"yomigana"
One of our customers decided to specialize in order to have sorting in
glossary

As said enough,
I am for the Eliot, Nancy's proposal for standardization in DITA data
model, align with HTML5 and ePub etc.

Tetsuya Sekine

======================================================================
Tetsuya Sekine
President, Principal Consultant
InfoParse, Inc.
<your one stop DITA contact/>
<DITA +                />
*email: ecmp@infoparse.com | Skype <callto://tetsekine>
*url: www.infoparse.com | phone: 81 3-3736-8180







On 2/2/12 3:42 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote:

The rational as I provided it to the TC during meeting was:

1. Ruby markup is essential for the publication of Japanese-language
documents (and for some other ideographic languages).

2. Japan is rapidly adopting DITA

3. Many DITA users localize their documents to Japanese

4. Without a ruby solution, Japanese users either cannot use DITA or will
be
forced to invent their own individual specializations.

Nancy Harrison echoed the fact that ruby markup is essential for Japanese
documents.

5. The ruby markup is well-defined in HTML and needs no refinement from
us.
Therefore, the standardization cost to the TC is very low (and in fact
I've
already done everything except write the language reference topics since I
originally implemented this in DITA for Publishers).

6. The rendition implementation is trivial for HTML outputs and available
for PDF outputs (i.e., Antenna House have developed particular XSL-FO
patterns for rendering ruby annotations).

Note that in my proposal the ruby markup is packaged as a separate domain
and would presumably not be integrated into the generic document type
shells
provided by the TC and so would not add to the set of elements seen by
default for typical DITA users using default document types.

Cheers,

E.

On 2/2/12 4:33 PM, "JoAnn Hackos" <joann.hackos@comtech-serv.com> wrote:

Hi,
Eliot, could you put together a rationale for adding Ruby support that
we
can present to the Translation SC? I have your original email to the
DITA
TC but what I need is why this is valuable for the entire DITA
community.
The SC didn't think that was true when we were reviewing DITA 1.2
proposals.

Thanks,
JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
Joann.hackos@comtech-serv.com
303-232-7586







On 2/1/12 3:06 PM, "Rodolfo M. Raya" <rmraya@maxprograms.com> wrote:

Hi,

It would be indeed interesting to pass the new proposal to the
Translation
SC for analysis.

Is there anything really different in the new proposal for adding Ruby
support? What has changed that could make the Translation SC change its
opinion?

Regards,
Rodolfo
--
Rodolfo M. Raya       rmraya@maxprograms.com
Maxprograms       http://www.maxprograms.com
-----Original Message-----
From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On
Behalf
Of JoAnn Hackos
Sent: Tuesday, January 31, 2012 10:14 PM
To: Eliot Kimber; Richard Hamilton
Cc: DITA TC
Subject: Re: [dita] Proposal: Domain for Japanese ruby markup ala
HTML5

I think this proposal needs to be discussed by the Translation SC.
Let's
see if
we can reconvene it. We considered Ruby markup for DITA 1.2 and
decided
against recommending it. I don't know if the members of the SC think
differently today.

JoAnn

JoAnn T. Hackos, PhD
President
Comtech Services Inc.
710 Kipling Street, Suite 400
Denver, CO 80215
Joann.hackos@comtech-serv.com
303-232-7586







On 1/25/12 10:21 PM, "Eliot Kimber" <ekimber@reallysi.com> wrote:

Good point--the markup is primarily driven by Japanese requirements
but
it is not unique to Japanese typography as you say.

Cheers,

E.

On 1/25/12 11:18 PM, "Richard Hamilton" <hamilton@xmlpress.net>
wrote:

Eliot,

I agree that it probably should be a domain, for the reasons you
describe.
However, there are other languages where a phonetic "ruby" could be
useful.
I've seen the same kind of thing in Chinese texts (mostly in
language
learning  aids), and I'm sure there are other uses.

So, I would suggest that any specification description not imply
that
usage is  limited to Japanese.

Best Regards,
Richard
-------
XML Press
New from XML Press:
WIKI: Grow Your Own for Fun and Profit
http://xmlpress.net/publications/wiki-how-to-grow

On Jan 25, 2012, at 8:56 PM, Eliot Kimber wrote:

HTML5 provides an improved version of HTML 4's <ruby> markup, which
is  required for Japanese-language documents that include kanji
(ideographic)
characters.

In Japanese, the pronunciation of ideographic characters cannot
always (or
often) be known from context. The ideographic characters are
annotated with  their phonetic transliteration, a "ruby", which is
rendered above or beside  or following the ideographs. This is
standard Japanese typography.

In the context of the DITA for Publishers vocabulary I have defined
a direct  copy of the HTML5 markup design, e.g.:

<p> 探険船シビリアコフ号の北氷洋航海中に撮影されたエピソ
ード映画の中に、一頭
の<ruby>
<rb>白熊</rb>
<rp>(</rp>
<rt>しろくま</rt>
<rp>)</rp>
</ruby>を射殺し、その子を生け捕る光景が記録されている。
</p>
Implementing this for HTML output is trivial--just copy to output.
For PDF  it's a little more work but can be done in XSL-FO.

<ruby> and its ruby-specific subelements are specializations of
<ph>.
I am proposing this as a new domain simply to keep the vocabulary
isolated  so that non-Japanese-language documents need not include
this markup.
But it
would equally appropriate to add it to the DITA base vocabulary as
well.

The Ruby markup works as expected in most modern browsers and in at
least  iBooks for EPUB. I have not tested on Kindle Fire.

The HTML5 specification for <ruby> is here:

http://dev.w3.org/html5/spec/Overview.html#the-ruby-element

The D4P vocabulary module and HTML implementation for the Open
Toolkit is  available as part of the DITA for Publishers package,
dita4publishers.sourceforge.net.

Cheers,

Eliot

--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.comwww.rsuitecms.com



--------------------------------------------------------------------
- To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org

--
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.comwww.rsuitecms.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.comwww.rsuitecms.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org


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