[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] Concerns for the Foreign-Element Fall-back
In reporting on this topic back on the SC34 WG6 list, I provided more analysis about the flattening procedure that is used when a foreign element appears in mixed-content (along with other conditions related to <text:h> and <text:p> ancestry). I am including the additional text here for the record and to further the discussion. I also note, in passing, that when a foreign element is flattened because it is not recognized by a consumer, there is no way for the consumer to determine whether the foreign element has mixed content or not, and therefore the interpretation of white space in the spliced-in flattened material is unclear. There might be actions that the foreign-element producer could take to assist in that being handled properly (perhaps by using xml:space). The more I look at the complexity of this, the more it looks to me as if, instead of stripping the foreign-element tags, they might be replaced with <text:span> tags and perhaps <meta:span> if needed. This would be in order to preserve RDF dependencies, xml:id, and namespace declarations (with appropriate precautions in case the binding for the text namespace is changed in the foreign-element tag). I haven't looked more closely at the impact that either flattening or spanning have on the occurrence of <text:change*> elements in the content of the foreign element. - Dennis -----Original Message----- From: sc34wg6-bounces@vse.cz [mailto:sc34wg6-bounces@vse.cz] On Behalf Of Dennis E. Hamilton <http://mailman.vse.cz/pipermail/sc34wg6/2010-May/000098.html> Sent: Thursday, May 27, 2010 20:37 To: SC 34 WG 6 mailing list Cc: Michael Brauer Subject: ODF Extensibility and the Foreign-Element Fall-back mechanism Following the 2010-05-26 Teleconference discussion of ODF Extensibility, I wrote down some of my thoughts on how it is difficult to introduce extensions, such as using MCE as a foreign element that carries further extension material, when the consumer does not recognize the extension (or the MCE mechanism). After the teleconference, I posted a simple statement of my concerns over foreign-element rules on the ODF TC list. That note is forwarded at the bottom of this message. Fundamentally, there is no required consumer behavior for the treatment of foreign elements encountered in an ODF document. In addition, when the foreign element occurs as part of mixed content, the *recommended* behavior is to strip the start and end tags of the foreign element and leave anything else in place to be consumed as part of the mixed content where the foreign element occurred. (I am oversimplifying although it would be great if it were nearly that simple. It is essentially this flattening that I point out is incompletely specified in item (1) in the forwarded note, below. It is also not stated in ODF 1.2 whether this flattening can continue recursively on what may now be seen as foreign elements in the just-flattened mixed content.) Another problem has to do with a principle that applies generally in ODF pretty much. Basically, the only time an element body can have PCDATA is when that PCDATA is textual content of the document. The idea is that, if all you wanted to do is extract the narrative text from a document in the sequence in which it occurs, all one needs to do is strip all of the element tags. This doesn't work 100%, but that is the essential idea. (The exceptions include hidden text, annotations, and removed material that is held as part of change-tracking.) Here is where there is a problem with MCE Alternative Content. If the occurrence is as an element in mixed content, and the <mce:AlternativeContent> element is flattened, all of the choices and any fallback will be flattened with it, and their flattening will likely lead to an undesirable result in any resulting mixed content. There is one mitigation (and it is different between ODF 1.0/1.1 and ODF 1.2). In ODF 1.2, the office:process-content element (being deprecated in 1.2!) could be present and set false on all of the <mce:Choice> elements to *recommend* (sorry) to a consumers that the <mce:Choice> element not be interpreted. Then the <mce:Fallback> element could determine the result (including by its absence) in the case MCE is itself not understood by the consumer. To accomplish the same sort of thing with an ODF 1.1 document, there are different rules for when flattening happens and the definition for office:process-content (and the default in its absence) differs. I am sure that I missed some cases and could have simplified this explanation more, but this is what I understand about ODF 1.2 extensibility at this point. - Dennis -----Original Message----- From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] <http://lists.oasis-open.org/archives/office/201005/msg00356.html> Sent: Wednesday, May 26, 2010 07:03 To: 'Michael.Brauer@Sun.COM' Cc: ODF TC List (office@lists.oasis-open.org) Subject: Concerns for the Foreign-Element Fall-back Michael, here is more on my concerns about the foreign-element handling in ODF 1.x and needing the fall-back to be predictable by producers who want to be careful that consumers will achieve a reasonable result: 1. The substitution process is incompletely-specified. I.e., if a foreign element has namespace bindings and use of XML-defined attributes (xml:lang, xml:space, xml:id, RDFa attributes, etc.), those need to be absorbed somehow if the tags are simply dropped and the body retained as part of the text. (I was thinking that a substitution with <text:span> Might be preferable because of this. Also, being in a place where <text:span> is allowed would be a good place to specify where this form of rewriting should be done. If <text:span> is not allowed where the foreign element occurs, then leaving the body should not be provided for. 2. The use of SHOULD in ODF 1.1 and ODF 1.2 is as "recommended." There is no requirement that it be implementation-defined or that there must be justification over doing anything else. (That is in the IETF RFC, but not the JTC1 definition of the provision. 3. Considerations for preservation of foreign elements/attributes that are not understood/supported seems to be problematic. 4. There is no consideration for how all of this fits in with change tracking and RDF markup. - Dennis - - - - - - - - - - - - - Standards are arbitrary solutions to recurring problems (R. W. Bemer) Although not by becoming the recurring problem (orcmid). When you find yourself in a hole, stop digging. --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]