Hi Jonathan, > To move the discussion from Issuezilla [0] to email...
thanks. > 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 see your point here, but the problem with this interpretation is that @form:name has - in ODF versions up to 1.1 - been defined with a different semantics. In particular, it has not the character of an ID, since it must not be unique at all. So, when we continue the line of your arguments, this would mean that ODF 1.2 would re-defined the semantics of @form:name to really be a unique identifier, which would pose problems with existing ODF processors, in particular when writing documents. An example would be OpenOffice.org itself, which would need to prevent, in its API implementation, non-unique names. Alternatively, it would need to store the API-name in a (to-be-introduced) attribute different from @form:name, which would cause even more trouble with document processors which perhaps script OOo to create documents, and process them further. So, as much as your analogy is true when considered for itself, there's no room for it in the existing ODF 1.1 standard, and existing ODF processors. > 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). It's not for meta data, it's for connecting the form control models to the shapes. I think there could be a way to reuse it, see below. > 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. Nice idea - do we already have something similar to this in ODF? Would this namespace be part of the ODF spec? If not, to which degree would such a document be a "valid" (in whatever weakened sense) ODF document? Is there perhaps allowance in the ODF standard or a certain class of "experimental" namespaces such as the one you suggested? Another idea might be to in fact introduce a property "ID" (or so), which we require to be unique within the document. This ID could be written as @form:id, we just need implement some additional logic. For instance, when importing controls in Excel documents, Excel's "GroupName" would need to be mapped to "Name", and "Name" to "ID". Sadly, for UNO dialog controls, this won't work, since their "Name" (in opposite to form control's name) has always been used with an ID-semantics. So, for those, "GroupName" would need to be imported as (to-be-introduced) "GroupName", and "Name" as "Name". Which is bad, since then the OOo API for form controls and dialog controls would be different, but, well, ... Also, care has to be taken in the form/component implementations since the ID needs to be document-wide unique - this has to be ensured somehow. Perhaps also auto-generation of IDs at runtime is necessary. Import/Export of form controls also would need adjustments, of course. The UI in the property browser might also need to be changed - perhaps we would want to make it more clear that "Name" in fact is a "GroupName" property - for some controls, at least. Not sure. Ignoring the open questions for now, do you think this is would be a reasonable approach? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
