On Thu, 2008-12-04 at 10:36 +0100, Malte Timmermann wrote:
> BTW - before I start:
> We talk about ODF here, so please avoid phrases like "You can say
> that you are like HTML, but you're not".
> This sounds like "you/ODF is this way, but we/OOXML would like...".
Actually, I did this work *before* I did any OOXML work. It was done
for .xls interoperability.
So I was intending to say "you/ODF says you're like HTML, but you're
not, because HTML supports XXX while ODF doesn't."
> In the end we both agree, it must be possible to have different
> identifiers for defining the group and for accessing the individual element.
>
> So we might introduce an additional attribute for the group, or for the ID.
>
> You would like to add something for group, because it's more like in OOXML.
Actually, OOXML does this entirely differently; I proposed
forma:group-name because that was the suggested solution on the
dev@dba.openoffice.org list. OOXML still has separate ids and group
names, but they're not located on the same element.
(Specifically, in OOXML the `id` is stored in
a /worksheet/controls/control/@name attribute, while //control/@r:id is
a resource reference to the actual radio button, which in turn has
a /ax:ocx/ax:ocxPr[ax:name="GroupName"] element
where //ax:ocxPr/@ax:value contains the group name. ~Completely
different than the proposed form:group-name attribute. ;-)
> I suggest to add something for ID - for compatibility reasons, and maybe
> it would also be/stay more similar to HTML.
The problem is, compatibility with *what*? This is a classic "damned if
you do, damned if you don't" scenario.
If we introduce something for ID, we "break" scripting, or need to
require that scripting check for both form:name and the ID attribute
values (and then what happens if both are provided? is it sane to have
two different names for the same object?).
Alternatively, we introduce form:group-name, and break existing apps
which assume that form:name is the only way that radio buttons are
grouped.
I have no real preference which way we go, I'm just trying to point out
that there are disadvantages to either approach. The advantage to
form:group-name is that we have code to support it now (and/or code we
can alter to support it now, take your pick), while I have no idea what
would need to be done to the OpenOffice.org scripting infrastructure to
support an ID attribute.
> My concerns with compatibility:
>
> Grouping support shouldn't break in existing applications.
> Of course you can provide patches like suggested below for different
> apps, but this doesn't help older apps loading newer documents.
> And you can't know how many apps/tools out there already rely on the
> existing mechanism.
True, but there could be any number of features that get added that,
when used, will cause older apps to mis-treat the file or load it
erroneously. For example, what if we add a new spreadsheet function in
a future version of the spec? Older apps won't support the function,
and thus there will be errors when older apps try to load the file.
So yes, this is an issue, but I'm not convinced it should be of primary
importance. As far as I'm currently concerned, the real question is
"which do we want to break, scripting or grouping?"
> I must admit that my suggestion is mainly based on technical/practical
> considerations.
My suggestion is based on talks on dev@dba.openoffice.org, which
suggested adding the form:group-name attribute. :-)
Introducing an equivalent for ID wasn't even mentioned, though there
were only 2-3 people involved on that thread, iirc...
> >From an aesthetic point of view I would more like the group-name ;)
>
> Malte.
>
>
> PS: I think we all agree that this is not an Accessibility issue, so the
> main ODF list is probably the better place to discuss this...
Yes, but it's the accessibility list which nixed the form:group-name
proposal when it was originally introduced. :-)
So I figure if we can get the accessibility list to approve, it will
actually have a chance of passing.
- Jon