Hi Jonathan, sorry, after pushing you to use the mailing list for all those discussions should have sent my previous mail too the list, too. So, for the record, I copy it here ...
--------- snip --------- Hi Jonathan, as a preface, let me say that in my understanding (I didn't mention this explicitly yesterday), this week's vote in the TC was not about which proposals are to be accepted or rejected at all, but about which 5 proposals are the most important ones to get int 1.2. Is this correct? If so, then the door would be open for discussing the form:group-name again for 1.3. However, my confidence that this will finally be accepted is fading away ... I am not as near at the TC as you are, so perhaps your impression is different. > This was discussed briefly on the office-accessibility list, and in > order to fix up the ambiguity/"collision" between control names and > group names both using the same element (form:name), Michael suggested > that we instead use xml:id to hold the control name while form:name > would be used ~solely for radio button group names. Letting xml:id hold the control name won't work, since xml:id must be unique within the whole document, which is not remotely ensured for form components (not even for sibling components, not to talk about arbitrary components in the complete hierarchy). What I think could be done, perhaps: - introduce an API representation of the xml:id attribute. Other objects in ODF documents support this attribute/property, too, so perhaps there's already some work done. What's interesting here is how the document-wide consistency of IDs is assured. For instance, if you copy'n'paste a control from one document to another, the ID must still be unique in the target document, which implies that the paste operation must be allowed to silently change it. I think there's some ugliness ahead on this way, but it should be manageable. - Introduce some XIdAccess::getByID, analogous to the existing XNameAccess::getByName, which allows scripts to access form components by their id. - Introduce an UI in the property browser, for changing the ID. - rename the "Name" property to "group name", and remove it for all control types except radio buttons. (not sure about the latter. Would make tweaking existing documents difficult, probably.) - don't touch the relation of Name<->form:name, for compatibility reasons What I'm uncertain about here is MSO. I know they have "old" and "new" controls (at least in excel), with different property sets. Would those in all cases be mappable to the Name/ID pair of form controls? > So the question is, in what timeframe do you want a working > implementation? The form:group-name proposal is working _now_. Unfortunately, it doesn't produce ODF-conform documents, and not even documents which we can have strong hope for to become ODF conform. From a developer-for-end-users perspective, I do not like this, but in the current form, it has no good chances to get into OOo trunk. > The use of xml:id hasn't even been started, it will amount to a > complete rewrite of the form:group-name approach (as it's ~completely > different), and I have no idea if this will even work. (I can't think > of any reasons why it wouldn't, but I haven't worked with the > scripting code either....). Yes, unfortunately the complete GroupName work would be lost :(, since this property would not even exist anymore. In theory, all those considerations should have been done before implementing this, but in the real world, no developer ever does ... which explicitly includes /me. > So if we want something soon, we need form:group-name. If we can wait > awhile (no timeframe), we can see if xml:id will work. I want a solution which allows component identity (currently done with Name - in some sense) and at the same time grouping control (currently done with Name, too). Inspired by MSO, I already said this implies implementing the GroupName property, but ... So, how to proceed? As said, in the current form, and assuming that the group-name proposal won't make it into 1.3, either, I cannot include your patch in trunk OOo. Whether or not you like to help implementing the ID approach as sketched above (really: *sketched*. In particular the Excel im/export is something I cannot remotely judge.) is your decision, finally. I'm willing to contribute my part, too - especially the implementation of the ID property, caring for all side effects, is certainly deep inside my core domain. So, what about working together on this, again? Thanks & Ciao Frank --------- snap --------- And Ciao, again Frank -- - Frank Schönheit, Software Engineer frank.schoenh...@sun.com - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@dba.openoffice.org For additional commands, e-mail: dev-h...@dba.openoffice.org
