[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] Informative clauses
robert_weir@us.ibm.com wrote: > > Sander Marechal <s.marechal@jejik.com> wrote on 06/23/2008 06:01:07 PM: > > > robert_weir@us.ibm.com wrote: > > > Let me connect the dots for you then, using ODF 1.1. > > > > > > ----- > > > > > > Section 1.4 "Relax-NG Schema" > > > > > > "The normative XML Schema for the OpenDocument format is embedded > within > > > this specification. It can be obtained from the specification > document by > > > concatenating all schema fragments contained in chapters 1 to 16. All > > > schema fragments have a gray background color and line numbers." > > > > > > ----- > > > > > > So the schema is declared to be normative. By using Relax NG we > have an > > > ISO-approved formal notation for indicating structural and content > > > requirements and options for XML. Since 2.4.2 "Base Settings" is > > > obviously a schema fragment (with gray background color and line > numbers), > > > this is included in the set of normative requirements defined by the > > > schema. > > > > I think what Dave is pointing to , is that there's nothing in the spec > > that says an application has to use <config:config-item> element to > > store it's application-specific base settings. It could store them > > anywhere withing the document tree using all kinds of non-inerop > extensions. > > > > The element is there. Just not the text that says an application > > should/must use that to store it's base settings. > > This is only partially correct. Section 1.5 of ODF 1.1 states: "There are no rules regarding the elements and attributes that actually have to be supported by conforming applications, except that applications should not use foreign elements and attributes for features defined in the OpenDocument schema. See also appendix D." So, if something is an application-specific base setting, then you should use the <config:config-item> element. Sure, one probably can discuss under which circumstances an information is an application-specific base setting. But if you take bold as an example: If you don't use the fo:font-weight attribute to store that piece of information, then you are breaking one of the "should" provisions of the specification. BTW: Appendix D actually informative specifies what elements and attributes are supported by typical office applications, so one could see this as some kind of informative profiles. > > Right. But that can be said of every feature of ODF, and indeed of > every XML-based standard that I can think of. It doesn't mean that they > are not testable. It just means that interoperability cannot be > guaranteed by a conformance test. But that is why this TC is needed, > right? If interoperability could be guaranteed by merely defining > conformance, then we'd have no work to do. That's all true. Michael > > -Rob -- 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]