[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]