About ruby in ITS global usage

This is my action item
http://www.w3.org/2006/07/21-i18nits-minutes.html#action01 on ruby.

The W3C Ruby spec defines an abstract content model for ruby, which is
implemented e.g. as a module for XHTML. "Implemented" means that

Ruby-1) The XHTML markup scheme contains the ruby module, and
Ruby-2) An XHTML user agent which processes ruby *markup* (that is,
independent of *markup declarations*) is expected to do appropriate
visualization of ruby, and / or to provide necessary editing facilities.

ITS defines abstract data categories, which
ITS-1) may be implemented in a markup scheme (conformance type "1: ITS
Markup Declarations" ), and
ITS-2) which may require ITS specific processing (conformance type "2:
The Processing Expectations for ITS Markup").

ITS-1) and ITS-2) have nothing to do with Ruby-1)  and Ruby-2). However,
to connect ITS to the Ruby spec (that is, Ruby-1) and Ruby-2)), we have
the conformance clause:

[[2-2: If an application claims to process ITS markup for the ruby data
category or the directionality data category, it MUST be compliant with
the external specifications referenced for ruby or directionality.]]

My argument at the 21 July call was that 2-2 does not make sense for
global ruby. Why? Because ITS requires for global ruby only processing
of the global selection mechanisms (see conformance clause 2-1-1) and
the precedence between selections (see conformance clause 2-1-3).

The result of such processing will be that the ITS information "this is
a ruby, rb, rt, rbc, rtc, an rp or an rbspan node" pertains to selected
nodes.  But that is different than what is required by Ruby-1), which is
not about nodes, but markup schemes. It is also different from Ruby-2),
which is not about node selection and pertaining information, but
visualization or editing. Ruby-1) and Ruby-2) could be built *on top of*
node selection and pertaining ITS information. But that is not the
business of ITS anymore.

You could argue that local ruby suffers from the same problems. But I
would reply: The difference between the local and the global case is
that the local case relies only on markup which is identical to the Ruby
TR. However, the global case relies on the application of XPath and
precedence rules between conflicting global rules. This creates a
mismatch which I think cannot be resolved easily. Here you see that my
argument is not only about "abstract" conformance clauses, but concrete
implementation issues: I think we cannto require  ruby visualization or
editing facilities relying on XPath.

Because of these conformance and implementation problems we should not
tell the HTML WG "You SHOULD / MUST integrate global ruby in XHTML".

My proposal: We should restrict the connection between the ruby TR and
ITS to the local ruby case. E.g., change conformance clause 2-2 to:

[[2-2: If an application claims to process ITS markup for the ruby data
category or the directionality data category *in their local usages*, it
MUST be compliant with the external specifications referenced for ruby
or directionality.]]

Btw., I think the same issues arise with directionality, and the same
restriction might be necessary. The local application of directionality
requires an implementation to understand the bidirectional algorithm,
because the values of the @dir attribute influence its behavior. I don't
 think we can require this for the global case: how should one implement
the BIDI algorithm and have it interact with XPath ...?

In summary: the global usage of ruby and directionality has *no story
about the relation to other specs*, but just uses the ITS global
selection mechanisms.

Comming back to XHTML, I don't think it makes sense for their
implementation of ruby and directionality to talk about ITS at all,
since XHTML already implements what we request: Ruby and Bidi. Hence, it
seems more appropriate for XHTML to cite the ruby TR directly. We could,
however, ask them to add a note about the global usage of ruby.

Looking forward for feedback,

Felix