Hi Jon, I think going with the interop namespace is the way to go. Or to put it in Tim Brays words: Who could possibly be against it? <http://www.tbray.org/ongoing/When/200x/2005/11/27/Office-XML>
Additionally I really like the TC chairs to update the information on http://wiki.oasis-open.org/office/Grouping_for_Radio_Elements. It does not state that its rejected at the moment. Lets see whether we can get more info. So I think we should go with the interop namespace and once we recieved the feedback from the TC we can solve this in one of the upcomming ODF releases. ~Florian >>> Jonathan Pryor <[EMAIL PROTECTED]> 09/22/08 5:20 PM >>> To move the discussion from Issuezilla [0] to email... Background: All Excel controls have a Name property which is used for scripting (i.e. you can directly use the control's name from VBA script to manipulate that control). Excel radio buttons have a GroupName property which is used to control which radio buttons are in a group. This is more or less directly mappable to HTML's //option/@id and //option/@name attributes, where @id can be used for scripting and @name controls radio button grouping. The problem: When importing .xls files, Calc would only import the Name property and not the GroupName property, thus breaking all .xls files containing radio buttons, as every radio button would be in a separate group after import. This renders radio buttons ~useless in interop scenarios. The solution: We have a patch to rectify this, and in the process adds a GroupName property to Form and related controls. If GroupName isn't set, then Name is used for grouping as before, maintaining backward compatibility. If it is set, then GroupName controls grouping, allowing .xls import to set GroupName and sanity to prevail. This solution also adds a //form:radio/@form:group-name attribute to ODF to persist this new property, so that it's actually useful within ODF documents. The problem: The above solution was rejected by the ODF TC, for reasons that aren't fully understood, but apparently are because this @name/@group-name dichotomy was not sufficiently similar to HTML and other W3C standards. The question: Where do we go from here? I'm of the opinion that we _are_ following W3C standards, give or take an attribute name change -- W3C defines two attributes for this scenario (@id and @name), and the above solution has two attributes for this scenario (@form:name and @form:group-name), but I don't think this logic will go anywhere. I've noticed that ODF also has a @form:id attribute as well, but it seems that it would be difficult to "re-purpose" this attribute to store control names (as the value is apparently transient, for use with metadata). So I'm at a loss as to what to do next. The only other possible solution I've heard is to place the group-name attribute into the interop XML namespace, thus we'd have //form:radio/@form:name and //form:radio/@formx:group-name attributes, where `formx` would be the "urn:openoffice:names:experimental:ooxml-odf-interop:xmlns:form:" XML namespace. Thoughts? - Jon [0] http://www.openoffice.org/issues/show_bug.cgi?id=30823 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]