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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

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