Hi Rob,
On 11/22/08 12:07 AM, robert_weir@us.ibm.com wrote:
> We can call it anything of these things (processor/interpreter/parser) so
> long as we explicitly define what that term means. The level of
> description from the SVG Recommendation is fine. My preference would be a
> term that denotes consumption of ODF, similar to how generator implies
> production of ODF. In fact, Producer/Consumer is a natural pair, as is
> Reader/Writer, or Generator/Parser. But Generator/Processor does not (to
> my ear) have that kind of equivalence.
>
> What do others think on this?
My favorite terms out of these are producer and consumer.
I can't really say why I prefer this compared to Reader/Writer. For the
pair generator and parser, parser sounds too low level for me. Maybe the
reason is my background in software development, where the term parser
is used for components that analyze files or streams pure syntactically.
>> I have thought about this myself for a long time. One reason why I have
>> added the "loose" conformance class was that we allowed foreign elements
>> in ODF 1.0 and 1.1. The other reason was that vendors may have
>> the issue that they have to store some information in a file
>> immediately, for instance because a customer requested this, and cannot
>> wait for the next ODF version. The assumption here of cause would be
>> that they propose the extension to the ODF TC, so that it would be used
>> only temporarily. In so far, there may be indeed better solutions than a
>
>> separate conformance class. I will think about this.
>>
>
> We can't stop vendors from adding extensions like this. But we are not
> required to add a conformance class for them either. We could just say
> that such documents are not conformant to ODF 1.2.
>
> It is always a trade-off and there is no clear "right answer", but at the
> extremes we can have:
>
> A) A very loose definition of conformance that allows many ODF vendors to
> claim conformance because the mandatory requirements are very few.
>
> or
>
> B) A tight definition of conformance that may result in fewer conformant
> ODF applications, but the ones that are conformant are more likely to be
> interoperable.
I agree. These are the two extremes. And we cannot prevent that someone
extends ODF. We can only make statements if and under which
circumstances an extended ODF can be called ODF.
If we have something like a loose conformance, then it is easier for
implementors to justify why they did extend ODF. But on the other hand,
we may encourage them to at least document the extensions.
So, taking it all together I'm still undecided here.
>>> Do we want to require a specific XML character encoding?
>> XML requires UTF-8 and UTF-16. I would not extend this.
>>
>
> I meant, do we want to leave this open-ended in ODF, that any character
> encoding may be used? Or should be require a conformant document limit
> itself to one of a smaller set of encodings? For example, OOXML restricts
> itself to UTF-8 or UTF-16. This is a good thing, I think.
Maybe, yes. Maybe, no. My personal opinion is here: XML optionally
allows other encodings. I don't know for what reason, but I assume that
there are reasons for this. ODF is an XML application. I therefore would
just adopt what has been defined by the designers of XML and would only
consider to restrict this if there are reasons to assume this definition
causes problems within ODF, or if we have to assume that the reasons why
XML supports other encodings do not apply to ODF.
>> If we keep the loose conformance, then I have no objections in turning
>> this into a shall.
>>
>
> That's an option. So I think I'm hearing three choices:
>
> A) As we have it now -- Loose and "Strict" document conformance, both with
> recommended documentation requirements
>
> B) Only strict document conformance, but application conformance would
> have document processing rules that would define how foreign
> elements/attributes are processed. (Although such documents would not be
> conformant documents, we can certainly specify how conformant applications
> treat them.)
>
> C) Loose and strict document conformance, but loose application
> conformance (applications that write loose documents) would have a
> documentation requirement, not merely a recommendation.
>
> My preference here would be for B. What do others think?
There is also an option D) (and most likely many more):
D) Loose and strict document conformance, but no loose application
conformance (applications may write loose documents, but they must also
be able to write strict documents) plus a documentation requirements.
I'm still undecided, but my preference is either B) or D).
Best regards
Michael
--
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH Nagelsweg 55
D-20097 Hamburg, Germany michael.brauer@sun.com
http://sun.com/staroffice +49 40 23646 500
http://blogs.sun.com/GullFOSS
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering