RE: [office] One strictly conforming document?

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

In the Expanded RDF Deployment example, below, there is an incomplete
attribute entry.  I meant for it to say

   It would be useful to use <xhtml:span office:process-content="true"> 
   elements to place spans and RDF markup that cross paragraphs and 
   sections of texts without using the bookmark mechanism.   

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org] 
Sent: Wednesday, February 04, 2009 15:37
To: 'Bob Jolliffe'
Cc: 'ODF office'
Subject: RE: [office] One strictly conforming document?

Bob,

I do have thoughts on ways that foreign elements might be very useful.

But that is not the basis for my arguing for perpetuation of the ceiling
that is established with ODF 1.0/IS 26300/ODF 1.1.  Although I would be
disappointed to see removal of the opportunity for foreign elements as part
of a compliant document, I can live with that, if the guidance about what to
do with them remains the same as for ODF 1.0/IS 26300/ODF 1.1.

My basis for keeping the current ceiling and the foreign-element conditions
is with regard to the promise that represents (as far as I am concerned).  I
have responded about that here
<http://lists.oasis-open.org/archives/office/200902/msg00046.html>
and further here
<http://lists.oasis-open.org/archives/office/200902/msg00053.html>.  I don't
need an use case to preserve that ceiling.  I also don't require knowledge
of whether implementers have made use of the provision or are intending to.
I don't have to be concerned about that prospect if we don't change the
provision (or if we propose to deprecate it as a candidate for future
removal but not remove it yet).

Furthermore, with the introduction of strict conformance as a normative
level, along with strict producers, I would think that your concern to
procure only strictly-conformant ODF processors is now supported in the
definition of the ODF 1,2 standard itself.  That strikes me as a good step
toward a single unity, at least in the field of endeavor that concerns you.
We have not made the current situation worse in that regard.  With regard to
the interoperability failures that worry you, I think you can now
concentrate on how to eliminate those below the strict conformance ceiling.
That remains the daunting challenge as well as I can tell.

EXAMPLES
--------

I am interested in ways to smoothly degrade from extensions (including
extensions of ODF itself) so that down-level interoperability works as well
as can be expected.  I am only interested, myself, in extensions that can
always be filtered to strictly-conformant documents without loss of
important features, and that will roundtrip with an extension-aware
processor when the extension markup is preserved and also well-enough when
it isn't.

STYLE-EXTENSION ATTRIBUTE EXAMPLE 

This involves a technique that Florian Reuter discussed at the meeting where
I first met him and Patrick.  For a concrete example, consider the
underlining feature, where a processor has support for the text-underline
style "fence", perhaps for compatibility with some legacy documents and
software.  

If this value is added directly to the value set of
style:text-underline-style there is the problem that this can't be done as a
foreign value (because the style namespace belongs to ODF), although a
future version of ODF might add it.

Even if there is a future version addition, the problem is that down-level
the style may be unknown or unsupported and there is no default available
for style:text-underline-style (other than "none", in the absence of
style:text-underline-type too).

A way to degrade more softly than this is to define a new namespace
(abbreviated here with the QName prefix "xstyle:") such that
xstyle:x-text-underline-style="fence" can be used.  The rule for
xstyle:x-text-underline-style is that it over-rides any
style:text-underline-style, so that both can be present.  That way, when
xstyle:x-text-underline-style is viewed as foreign or not supported, it will
default to the provided style:text-underline-style.  Under this principle,
when there might be eventual introduction of this into an ODF-specified
namespace, any xmlns:xstyle= could be replaced to use that now-official
namespace and everything still works, including for downlevel
implementations of older ODF-conformant consumers that recognize neither
occurrence of x-text-underline-style.

LAYOUT HINTS

In interoperability conversations, there are problems with differences in
hyphenation algorithms, how line justification works, font metrics, etc.,
and it would be nice for a processor to be able to hint to others how it
presented the document.  One could invent a <xtext:hbreak /> element to
indicate where a hyphenation break actually occured.  Production of the
hyphen and inheritance of any hyphen-character choice is implicit in the
element, which may have further attributes that help knowing how to discard
the hints when they are no longer applicable.   As a foreign element, it is
discarded/ignored and introduces no content.

Similarly, one might have <xtext:line /> and even <xtext:page> where
automatic line and page breaks were inserted.

If there are layout hints in a document, there is probably a metadata
element that announces their presence and also provides a way to identify
the hints with the last-made presentation.  Absence of the metadata
information means that any residual layout hints can all be ignored and
should be stripped when an opportunity presents itself.  This is also the
proper down-level behavior.

EXPANDED RDF EMPLOYMENT

The current use of in-line RDF is pretty much limited to the interiors of
table cells and at the paragraph content level.  It would be useful to use
<xhtml:span office:> elements to place spans and RDF markup that cross
paragraphs and sections of texts without using the bookmark mechanism.  

ALTERNATIVE SPREADSHEET FORMULAS

An ODF Spreadsheet implementation has been developed to be compatible with
the OO.o table:formula that OpenOffice.org implements.  In switching to
OpenFormula, lets suppose there are OO.o forms that are not supported or not
supported the same way.  (Many others just work, let us say.)  There is no
way to provide two table:formula attributes so that one or the other can be
chosen.  Some sort of xtable:alt-formula attribute would allow an
alternative to be provided when the given one might not be understood
properly.  So if the formula scheme of the alt-formula is understood, it
should be used, and the table:formula should be used if not.  The default is
to the table:formula in this case.  (I can think of another case where the
consumer is told that the table:formula is all right to interpret as if it
had one or more other QNames, and I can think of metadata that provided some
of this in the cell and also globally for inheritance to the cells.)

I don't claim expertise in knowing which ones of these speculative cases
might work, but these are the sort that I have mused over from time to time.

 - Dennis 

-----Original Message-----
From: Bob Jolliffe [mailto:bobjolliffe@gmail.com] 
Sent: Wednesday, February 04, 2009 03:11
To: dennis.hamilton@acm.org
Cc: ODF office
Subject: Re: [office] One strictly conforming document?

Hi Dennis

Clearly you have far more time to devote to to this discussion than I
so you will forgive me if my response is brief.  I am trying to
understand where this strong demand for the use of foreign elements is
really coming from.  I've heard about the X standing for extensible,
the fact that html has a <div> element and an ongoing appeal to the
metaphor of floors and ceilings.  Somehow none of it is convincing.
Is there a real use case out there which is perhaps threatened by
"lowering the ceiling" as you would put it?  I am wondering whether
there is a known implementation, or planned implementation, which will
rely heavily on this allowance - or "promise" as i have heard it most
recently described.  If so, maybe we should be discussing in more
concrete terms.

[ ... ]


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