XForms and Text and RCC, Oh My!

Hi, folks-

I've been experimenting with implementing XForms using RCC (and some of the
other goodies in 1.2 that ASV6p1 provides). Based on some tests, I have a
few questions, comments, and requests to make.

First off, let me say that I'm very excited about RCC, and the many things
that you have done with the various text features.

I think that a few key features may be missing, though. First, and most
important, I think that in order for RCC to live up to its potential, it is
essential that some limited aspect of XPath be included. There was much
debate about this at SVG Open (and I'm sure within the WG), but there is
very little said about this in the 1.2WD itself, outside of the XSLT-nature
use-cases of Live Templates. Perhaps my concerns are misplaced, and you have
already dealt with the issues I'm about to bring up, but I thought it
important enough that it bears mentioning. I have attached an example of a
simple RCC XForms sample, which can also be found at:
http://schepers.cc/testbed/InstanceData.svg

In any arbitrary XML, one cannot expect concessions to visual appearance.
That is the job of SVG. You can't even count on having any attributes common
to SVG that you can leverage, or on the structure being remotely applicable
to SVG. The only thing that can be counted on  is a consistent internal
model of the data. XForms is slightly exceptional in regard to appearance,
since there is the expectation in most people's minds that the widgets will
look much like they do in HTML forms. One way in which XForms is not
exceptional is that in its syntax, for the sake of brevity, the nature of
any given element depends largely on the context --that is, its parent and
its attributes. I go into more detail in the attached example, but suffice
it to say that any given template needs to be able to access, at the very
least, the attribute values of the element being rendered, and the attribute
values and tagName of its immediate parent. This would make a huge
difference in how easily and flexibly the author could make RCC templates,
for what seems a rather modest set of features. I believe the precedent is
already there in <refContent>, and I doubt that any costs in implementation
and processing would outweigh that of the need for post hoc scripting it
would eliminate. Authors will expect to be able to "style" (or "skin") their
XML with fair degree of flexibility, and if they find they can't, they may
well discard SVG for their purposes.

Second, I'd like to know how editable text is going to be extended.
Currently, in ASV6p1, only the text element can take this attribute. I think
that this should be extended to <tspan>, and <tref>, and to <flowDiv>,
<flowPara>, <flowSpan>, <flowRef >, and <flowTref>. I think that there
should be nested focus targets (rather than the parent <text> element always
owning the mutation event), possibly navigable by delete events. Having this
fine degree of control over the text content will allow authors to make
extremely rich content with little or no scripting. I give an argument for
an editable <tref> in particular in my attached example, in reference to a
script-free implementation of XForms Instance Data (which should be useful
for Tiny).

SVG 2.0 is a long way away, and we are now in a crucial time for the
widespread acceptance of SVG. I feel very strongly that without some type of
XPath selectors in RCC in the 1.2 Spec, the funtionality of this very
promising
technology will be crippled.

Thanks-
-Doug