Re: [office] One strictly conforming document?

[robert_weir@us.ibm.com]

Patrick Durusau <patrick@durusau.net> wrote on 02/03/2009 10:03:41 AM:


> 
> The reason I find that problematic is that I may want to have an 
> application that never produces ODF 1.2 strictly conforming documents.
> 
> 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.
> 
> 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?
> 

In that case you have three choices:

1) Continue doing what you are doing, even if it does not result in it 
being a conformant ODF 1.2 document.  If you get value out of this 
arbitrary combination, then I'm not going to deny you the ability to 
innovate.  But it is a private combination that has no formal meaning 
other than what you privately ascribe to it.  Not only does the ODF 
standard not speak to it, this combination is out of scope for the ODF 
standard and for discussion by this TC since no specification of it has 
not been contributed to this TC.  Similarly, it is inscrutable to any 
consumer of the document, unless a previous private interchange of 
information has told them what to do with the style sheet.

2)If you think the combination is a particularly good thing and of general 
utility, then you could contribute it to the TC and we could consider it 
for a future release of ODF.  If we did so then some future release of ODF 
would specify the behavior of XSLT elements in ODF and allow them in 
conformant documents.  But I bet that you wouldn't bother to go through 
all that effort and delay to write high quality specification and to 
contribute your work and any contingent IP rights to OASIS, if your 
document could be called conformant without that effort?  If we call all 
extensions conformant then we've removed any incentive for vendors to 
standardize the underlying technology and make the disclosures and IP 
freely available.  I don't think we should cheapen our brand by giving the 
label "ODF Conformant" to arbitrary extensions.

3) If you would rather not work with us ruffians on the ODF TC, then you 
are always free to define a profile of ODF+XSLT in any other standards 
organization.  When you do that then you can define the semantics of that 
combination as well as conformance requirements.  This is common, for 
example, in the W3C, where they define profiles like XHTML+SVG+MathML 
rather than saying XHTML can contain arbitrary extensions.  In that case 
the extension would be conformant to whatever new profile you define.

In other words, if you want to do something beyond ODF, then just do it. 
But if you want that extension to be conformant, then you don't stretch 
ODF conformance to include any arbitrary extensions.  Instead, take your 
extension and standardize it, either in ODF or in a profile.  Until you do 
so, any extension is not conformant to the ODF standard. 

This should be intuitive and obvious.  If it isn't standardized, if you 
have not submitted your technology to the rigors of standardization and to 
the review and judgement of your peers, and and have not declared the IP 
related to the technology, then why should this TC be so lenient as to 
allow you to call call it conformant to the ODF standard that we've 
collectively worked over 6 years to create? Our coin should not be so 
cheap.

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

I think the presumption is that nothing is conformant unless it meets the 
requirements of the standard. The question for you is why should your 
arbitrary private extension be called conformant, when it meets none of 
the technical or IP disclosures that exist of the core parts of the ODF 
standard? 

But I'd ask you, what benefit, other than lack of labor, would you have by 
calling your arbitrary extension conformant that you could not also get by 
one of the alternatives 1-3 I gave above?  I think I've made a good case 
of the harm of allowing arbitrary extensions on conformant ODF documents. 
So can you please explain what you think the harm is of not allowing such 
extensions in conformant documents?  What exactly do you lose?

> 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 would assume that creators of non-strictly conforming producers aren't 

> going to conceal those capabilities. They are no doubt the rationale for 

> some feature, etc.
> 
> Hope you are having a great day!
> 
> Patrick
> 
> 
> 
> -- 
> Patrick Durusau
> patrick@durusau.net
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
> 
> 
> ---------------------------------------------------------------------
> 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 
>