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

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: RE: [office-comment] CD01 -- 8.2.1 Referencing Table Cells


Patrick

Well, the feature's in a bit of a mess in OOXML because of a (possibly
competing) concept of "conformance class" that applies to the "strict"
and "transitional" versions of OOXML.

Still, that's an opportunity for ODF to do better :-)

The problem you've still got in 1.2 is that is permissible for an
implementation to omit any feature and yet still be 100% conformant. So
(to take a hot-button example from the BRM) if a vendor decides to leave
out accessibility features, then by the letter of the standard, that's
still fine conformant behaviour.

> My assumption has always been that conformance clauses are useful for
> buyers to have a short-hand, "...do you conform to....(standard or
part
> of conformance clause)..." rather than having to specify particular
> abilities. Perhaps the customer whats an entire set of abilities.

Yes, so the big office suite vendors will no doubt want to conform to
something which parallels
http://descriptions.openxmlformats.org/description/full ("An application
conforming to this description has a semantic understanding of every
feature within its conformance class.") [N.B. "conformance class" in
OOXML means its strict or transitional variants.]
 
> So the real question is whether or not we have mechanisms that allow
> customers to specify particular sets of features, some, all,
particular
> ones and where should that be located?

Yes. As 29500 states: "It is also expected that third parties might
define their own application descriptions; for example to
inform their procurement decisions, or to deal with domains such as
accessibility."

> I understand you to be saying that OOXML has both internal definitions

Yes, "base" and "full".

> (assuming I can ever figure out what "...in a manner consistent with
> the
> semantic definitions..." (Part 1, 2.6, defining semantic
> understanding))

It means "doing what the standard says". Remember OOXML (notoriously)
originally stated that conformance was "purely syntactic" (rather like
ODF 1.0/1.1 effectively!)

> and allows any number of external definitions.
> 
> There appear to be no limitations on external definitions.

Agreed.
 
> I like the idea of specifying conformance classes and using URIs,

Knew you would ...

There's a bigger picture here of course ;-)

> etc.
> so there is merit in the mechanism. 

As I see it, in 1.2 you're hardwiring in two conformance classes
("conforming" and "extended conforming") and applying these to both
documents and applications. However (as I have written previously) they
are based around this academic distinction between own-namespace and
foreign-namespace element content. The underlying problem the user/buyer
faces ("does this ODF application do what I want?") remains unaddressed.
(N.B. "not having foreign elements" is not a real user requirement,
IMO.)

You could just add applications descriptions pretty much "as is", as ODF
already uses the term "conformance class" similarly to OOXML.

> I am less certain that what you
> have
> proposed is any more specific than what we have now.

The difference would then be that ODF procurers could specify (for
example) that they wanted to procure an ODF application which was of
conformance class "conformant" and which obeyed application description
"full" (i.e. it had to support all of the features of the standard).

If the TC fails to do this, it is leaving open a loophole for office
suite vendors to produce suites which have wildly different feature sets
yet which are all notionally "100% conformant". And you really don't
want to do that. Not again.

- Alex.





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