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] One strictly conforming document?

Michael and Patrick,

I think this is a very useful exchange.

Based on this and some other analysis I have been doing, I think it is
important to define a strictly-conforming producer.  

That strikes me as much better than saying that a conforming producer must
be able to produce strictly-conforming documents under various conditions.
The capabilities can obviously be combined in a single producer/processor
implementation, but now we don't have to make up rules about how such
implementations provide for selection of which producer, etc., so long as
the strictly-conforming producer is discretely usable somehow.  And people
who want always-strictly-conforming producers can obtain just those, or use
whatever options there are to limit an implementation to exclusive use of
its non-strict producer.

I'm also aligned with the independence of this from anything that ends up in
in-line or in-package RDF metadata.

 - Dennis

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Tuesday, February 03, 2009 08:10
To: Patrick Durusau
Cc: office@lists.oasis-open.org
Subject: Re: [office] One strictly conforming document?

On 02/03/09 16:03, Patrick Durusau wrote:
[ ... ]
> Let me say what I was reading and you or others can say if that was what 
> you saw as well:
> I was reading the conformance clause to exclude from ODF 1.2 conformance 
> an application that produced only a non-strictly conforming ODF document.
> In other words, an application that produced only ODF plus some unknown 
> extension could not claim to be ODF 1.2 conforming.
[ ... ]
> The reason I find that problematic is that I may want to have an 
> application that never produces ODF 1.2 strictly conforming documents.

This may be okay. What is important to me however is that one can differ 
an application of this kind from one that only produces strictly 
conforming documents.

Assume we have only one conformance level for producers, and this allows 
to produce conforming and strictly conforming documents. In this case, 
there is no way to figure out whether an applications that claims to be 
conforming is actually able to produce strictly conforming documents.

We can only solve this issue by either requiring that an application 
must be able to produce only strictly conforming documents on demand. Or 
we must have two conformance levels for producers. In this case, an 
application that claims to be strictly conforming must be able to 
produce only strictly conforming documents on demand. An application 
that does not have this capability may call itself conforming, but it 
must not call itself strictly conforming.

> For example, what if I write an XSLT stylesheet that adds custom work 
> flow management information to an ODF file and then stores that in a 
> package. When I sent that file to an ODF application, it simply ignores 
> the work flow management information that is solely managed by another 
> application. Since my application is only meaningful in terms of the ODF 
> 1.2 format, I would like to say that it is an ODF 1.2 conforming 
> application but obviously I am going to tell users that it uses 
> extensions for the CMS capabilities. As a matter of fact, it could be 
> the case that the consuming ODF application doesn't even preserve the 
> work flow information but that is added on every commit to the CMS.

I'm not sure if the the work flow management information would be stored 
as RDF/XML, or as extension to the schema. I therefore would like to 
clarify that the extensions we are currently talking about are 
extensions to the schema we use in content.xml, styles.xml, meta.xml or 
settings.xml. Whether an application stores information in a RDF/XML 
stream has no influence on whether it may call itself conforming.

> What value do you get by excluding my XSLT stylesheet from saying that 
> it is an ODF 1.2 conforming application, assuming that it accurately 
> reports that it uses extensions for the CMS capabilities?
> I mean for it to consume and produce ODF 1.2 documents for consumption 
> by other ODF 1.2 applications. Why deny me the label of ODF 1.2 
> conformance?
> Note that I freely grant that the conformance requirements can say: 
> Conforming applications must/should say whether they do a, b, c, or a + 
> b, etc. Just so I can compare applications in a meaningful way.

I think this is essentially what I mean by having two conformance 
levels. An application must provide the information whether it stores 
extensions, or does not do so. But we must provide the appropriate 
conformance levels, so that implementers can do so, and actually have to 
do so.

Best regards


[ ... ]

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