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

[Dave Pawson <dave.pawson@gmail.com>]

Your proposal isn't consistent Dennis.

2009/2/13 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.

I'll read that as 'all foreign elements', which itself needs clear definition.
Empty elements?
In all parts of the schema (e.g. what of parts of the schema which are
not normally displayed?)?

Without a lot of thought, my gut reaction would be to go the other way
and simply ignore all foreign content. Far easier to process, far less
room for embarrassment by implementers.



>   [Hey, pure document conformance. I like
> it!  Not 99-44/100%, but 100% pure ODF.

Needs to be said.

> 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).

rdf? Empty elements? extention attributes? It needs to be explicit.


>
> This seems simpler than the proposed modification to provide different
> flattening/elimination guidance for different parts of the specification.

Somewhat ridiculous I agree.


>
> 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.

Each section of the spec|schema needs reviewing in this light to take
this proposal forward
Dennis. You can't ignore any one.


> (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.

Which again needs a clean definition that can be coded.


> (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.

+1


>
> 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.)

Ah! At last. There are so few normative statements against which
conformance can be verified that all this hot air about conformance in this and
other threads is somewhat meaningless. The word 'shall' is somewhat lightly
used in the spec. And it's every section and para btw, not just the
table formula :-)
At least if we want a verifiable spec.


regards





-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk