RE: [office] The Rule of Least Power and Legacy Obligations

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

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