[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] The Rule of Least Power and Legacy Obligations
I find the HTML (excluding XHTML) approach treatment of unrecognized elements to be a worthy approach. My reading of the ODF recommendation for processing content of an unsupported/unknown foreign element in extended documents is the recursive application of Rob's case (3) for flattening away those foreign elements. If there are also (non-extended) conformant document cases where foreign elements are tolerated, I would apply the very same rule. I think we should not grandfather any foreign elements into the stronger conformance level, however. It makes no sense to me to tolerate foreign elements in a level being provided to satisfy those having a strongly-felt requirement for pure ODF documents. [Hey, pure document conformance. I like it! Not 99-44/100%, but 100% pure ODF. Even better than strict conformance. Finding the pure level of OpenFormula should be interesting too. Maybe that needs its own namespace?] It would seem that, based on the discussion so far, that an appropriate step would be to simplify the unsupported/unknown foreign element to this case everywhere. In the case where the resulting ODF-defined containing element has no provision for simple content, any resulting simple content in the flattening should also be ignored (collapsed to white space). This seems simpler than the proposed modification to provide different flattening/elimination guidance for different parts of the specification. It also strikes me, with the amount of back-and-forth here, that a cleaner way to deal with this is to (1) Provide guidance on foreign namespace usage in <style:*-property> and in metadata and everywhere else in the same way, using a consistent terminology. (2) Have only the one schema, essentially a complete version of the strict schema (3) Remind ourselves that being a foreign element, attribute, or value does not mean that it is an implementation-unsupported/unknown foreign element-attribute-value and we are only saying what is to be done in the unsupported/unknown case. This is valuable guidance regardless of some foreign e-a-v becoming well-known and candidates for de factor support and, ultimately, consideration as appropriate additions in future specifications. I claim that this is indeed the lively and robust way to deal with parochial needs and to provide provisional/experimental features in a benign way for those communities that value such things. One can then look at future ways of regularizing the specification, recognition, and adoption of extensions as no longer foreign. (4) Remind ourselves that the ODF 1.0/IS 26300/ODF 1.1 "conformant document" corresponds with the ODF 1.2 "extended [conformant] document" and that we owe it to our constituency to preserve that correspondence until there has been sufficient notice in the world that something else may happen in the future (for me, an arbitrary distant point called ODF 2.0). I do not find merit in the "what works in 1.0 stays in 1.0" argument, especially coupled with the expectation that supporting products will move whole-heartedly to ODF 1.2 support, creating the first-ever ODF legacy-document crisis for spreadsheets if not more. How is this even in scope? (5) Stop revisionist ear-marking of stuff, accepting that pretty much anything that was conformant before should be at least extended now. The new strong conformant [pure] document level should be a clean differentiation and if it requires strict use of namespaces (e.g., no scripts since there is no defined scripting language, and only OpenFormula formulas in table:formula), so be it. In my considered opinion, this should be all that we do to see if the new stronger [pure] conformance level has legs. I would not do anything more until we actually have 1.2 and we get to see how well the take-up of pure conformance occurs in implementations and procurement/adoption policies. Doing anything more on speculation seems inappropriate to me. We are going to find it difficult to talk about conformance in the body of the document because of the need to be specific about what certain normative statements are addressed to. Figuring out how to reword the section on table:formula so it says the right thing for both cases, and folks will recognize what is happening, is going to be challenging enough. (Although being able to say what MAY be done in an extended document and what SHALL be done in a pure document is sharper.) - Dennis PS: Just so you know my silence amidst this feedback overdrive indicates neither inattention nor acquiescence. -----Original Message----- From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] http://lists.oasis-open.org/archives/office/200902/msg00174.html Sent: Friday, February 13, 2009 07:59 To: Dave Pawson Cc: Jirka Kosek; office@lists.oasis-open.org Subject: Re: [office] The Rule of Least Power Dave Pawson <dave.pawson@gmail.com> wrote on 02/13/2009 10:11:46 AM: http://lists.oasis-open.org/archives/office/200902/msg00172.html > > Expected processing is the key to a standard, if of interest. > > Browsers set a 'standard' by defining the expected processing behaviour > to 'show text content as plain text'. That suffices for a browser. > > Ignore other uses of extensions until this aspect is defined for ODF. Dave, so I understand you perfectly, by "ignore" what exactly do you mean: 1) Don't allow them in conformant ODF documents? 2) Allow them in conformant ODF documents, but define a processing rule that says to ignore them? 3) Allow them in conformant documents, but do what HTML does, namely show the element content, presumably treating it as if it were content of the nearest ancestor node that is not in an extension namespace? 4) Something else? -Rob --------------------------------------------------------------------- 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]