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


I also think we are having a language problem.

I wasn't referring to how many xmlns:foo=... and xmlns=... declarations
there are but only if a foreign one is actually used, that is, an element,
attribute, or value that depends on that namespace occurs in the ODF
document.  Also, though I failed to mention it, I am also excluding those
foreign namespaces that are only used, via CURIES, to compose URIs in RDF
attributes, and not actually used as namespaces. 

I didn't mean to suggest it was the declaration of the namespace that was
important, but the reliance on the namespace as a namespace (excluding use
in forming URIs via the RDF CURIE mechanism, where there is no reliance on
the namespace URI as anything but a string).

Also, of course, the special use in ODF of QName prefixes within attribute
values is not subject to schema validation, as far as I know, since I think
we always say those attributes are of type string.  I suppose we can take
that up when we look at those cases, including table:formula, to see exactly
what is in and what is out at what level.

Just the same, I *do* count the use of QName prefixes in attribute values as
an use of a namespace.  It is not something trivial like a CURIE, it is a
determination of how the rest of the value is to be interpreted.  Sounds
like application/use of a foreign namespace to me.  We've not even required
that such a namespace usage be documented in any way, but it does determine
the syntax and other rules for the value of the attribute and it does
require that there be a related xmlns declaration.  If it walks like a
namespace, quacks like a namespace, and is called a namespace, and if it is
not an ODF namespace, why isn't it a foreign namespace?  Of course, ignoring
the attribute breaks the formula dependency of the value in the cell, but we
have given no guidance on what else to do that might work.  I have seen one
ODF 1.1 implementation that ignores any prefix in table:formula,
substituting one of its own choosing.

 - Dennis

PS: I really do like the idea of having new MIME types as a promise to
accompany the new stronger conformance level.  I think Jomar's idea is a
good one.  It is not necessary to use them, of course, since the stronger
conformance level is a subset of the weaker one.  I would object to using
the existing MIME types to signify the stronger conformance level because of
forward/backward compatibility issues.  Backward compatibility is probably a
reason not to monkey with the MIME types at all, though.  Because of that,
the current MIME types should not differentiate conformance level.  Ah well
... .

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Monday, February 09, 2009 02:57
To: dennis.hamilton@acm.org
Cc: jomar.silva@br.odfalliance.org; office@lists.oasis-open.org
Subject: Re: [office] Conformance Clause proposal, Version 8

Dennis,

On 09.02.09 07:20, Dennis E. Hamilton wrote:
> Jomar,
> 
> 
> PPS: Since the current mimetypes are already in use for documents that are
> conformant in ODF 1.0/IS 26300/ODF 1.1 terms, and certainly all
spreadsheet
> documents have been using at least one foreign namespace, maybe we should
go
> the other way and make new mimetypes for the new conformant-document
level.
> That is, "application/vnd.oasis.opendocument.text-ext" and ".odts" or
> ".odtl" or somesuch?

I think there is some mis-understanding: Whether a document contains 
declarations for foreign namespaces does not matter. What matters is 
only if this namespace is used as a namespace for an element or an 
attribute. Or to say it differently: What matters is whether a document 
is valid regarding the ODF schema we define. A document that adds some 
namespace declarations remains valid. A document that adds elements and 
attributes is not valid.

That means, even if you take the strict conformance definition that does 
not allow foreign elements and attributes, you can add as many namespace 
declaration as you want, and you can use them in as many attribute 
values as you want.

I have in principle no objections of having multiple Mimetypes for the 
conformance levels, but I'm not convinced whether having multiple 
extensions actually avoids confusion or adds some for the user.

Best regards

Michael


> 
> PPPS: I have already said that I would go along with "Extended Document,"
> although a better term would be welcome.
> 
> -----Original Message-----
> From: Jomar Silva [mailto:jomar.silva@br.odfalliance.org] 
> http://lists.oasis-open.org/archives/office/200902/msg00099.html
> Sent: Sunday, February 08, 2009 16:15
> To: office@lists.oasis-open.org
> Subject: Res: RE: [office] Conformance Clause proposal, Version 8
> 
> Advancing a little bit on this discussion, I believe that should be very
> useful to ODF users if we define a way to clearly (and transparently)
define
> the kind of ODF document they're dealing with (just in case that more than
> one conformance clause be approved).
> 
> With this scenario in mind, I would like to propose that we define
different
> file extensions and/or mimetypes to identify documents with contents based
> on different conformance clauses.
> 
> If Rob's proposal would be accepted, I believe that the nomenclature
> OpenDocument Extended should be used, meaning extensions as .odxt, odxs,
> .odxp and so on, but we also should define mimetypes to allow the
> differentiation on XML (not packages) ODF documents.
> 
> I'm waiting your comments (and I bet US$100 that Dennis will have several
> ones :) ),
> 
> Jomar 
> [ ... ]
> 
> 
> ---------------------------------------------------------------------
> 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 
> 


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



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