OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] Conformance Clause proposal, Version 8


Dennis

2009/2/6 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> Out of curiosity, if strict were reserved for the one that means with no
> extensions, what do you see that as leaving out?
>
> I would think that the <style:*-properties> and metadata foreign elements
> are handled in the outer level either way (although I don't think the
> recommendation as to their preservation is wise.)
>
> Do you agree with Rob that this would exclude the RDF metadata?  I can't see
> why.  I don't think RDF's provision for arbitrary vocabulary is thought by
> anyone to be an extension of RDF.  This notion of extensibility does not
> strike me as an extension of RDF, it is the very nature of RDF.
>
> Or would strict conformance exclude the use of table:formula values with
> prefixes from QNames of foreign namespaces?  Similarly for scripts?  If
> pressed, I would have to agree that those are extension points built into
> the specification.  I'm not sure which way someone who wants to have a
> strict ODF document would decide on this one.
>
> If you say that is the problem, I will abandon my preference of "strict
> conformance" as ours to define.
>
> Bob?
>
>  - Dennis
>
> PS: Bob, I add you to these questions because I don't know, for the single
> level that is the only one you are interested in, whether the things I'm
> asking about are included or excluded in your view.  Do you currently grant
> variances for certain namespaces or processors or do you regard the rules
> for RDF metadata and for the QName prefixes in table:formula and script
> codes as allowing permissible extensions, along with the
> <style:*-properties> and the metadata ones.

My understanding is that the rules for RDF metadata would permit
"extensions".  Though I'm not sure if I would say it is a good idea to
think of it as generic extension mechanism.

The current proposal regarding prefixes in table:formula seems to
quite clearly not allow extensions in conforming documents.   For a
conforming document this is as it should be, to avoid incompatibility
between spreadsheet applications.

Regards
Bob

> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM]
> Sent: Friday, February 06, 2009 04:03
> To: dennis.hamilton@acm.org
> Cc: 'OpenDocument Mailing List'
> Subject: Re: [office] Conformance Clause proposal, Version 8
>
> Hi Dennis,
>
> On 05.02.09 21:14, Dennis E. Hamilton wrote:
>> Michael,
>>
>
>> 3. I don't like the names very much, but that may be just me.
>
> I agree to Rob that we should reserve the term "strict" for something
> that may even be more strict than what we have today.
>
> The term "host language conformance" is a term that is used in other
> standards, too, and that very well characterizes this conformance level,
> without having to interpret terms like "strict" or "loose", which can
> have many meanings. So, why not use an established and "speaking" term
> here? Our charter says we should borrow from existing standards where
> possible. Why not use a term that is used in other standards, too?
>
> 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
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]