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] Re: CD01 -- 8.2.1 Referencing Table Cells


On Fri, May 8, 2009 at 6:36 AM, Alex Brown <alexb@griffinbrown.co.uk> wrote:
> This issue about normative text and ISO verbal provisions keeps cropping up on this list. I've given it some more thought and looked at many XML standards drafts and I think I'm going to disagree with you about how to apply the JTC 1 requirements when it comes to authoring an XML standard built around a normative schema.

Sorry for the delay in getting back to you. Other matters required my
full attention. I appreciate your thoughtful criticism.

> I'm assuming that a schema exists (as it does for ODF), and that the text clearly states that the provisions of the schema are normative.
>
> That said, assume (for the sake of example) we have an element <a> for which the schema declares a REQUIRED href attribute.
>
> Now if this was documented in ODF, my guess is the spec would say something like:
>
> [ex 1] The <a> element represents a hyperlink. Its href attribute is used to specify a URI reference which conforms to RFC blah blah
>
> I believe you want it to say something like:
>
> [ex 2] The <a> element shall represent a hyperlink. Its href attribute shall specify a URI reference which conforms to RFC blah blah
>
> Now, I actually think [ex 1] is okay, because the normative schema mandates that the attribute has to appear. In this light the narrative text is a commentary on the normative provisions of the schema. In fact, I prefer [ex 1] because it is more idiomatic (at least to me, as an English speaker) than [ex 2].
>
> What I don't think is okay is:
>
> [ex 3] The <a> attribute shall be used represent hyperlinks. Its href attribute can be used to specify a URI reference which conforms to RFC blah blah
>
> As the "can be" implies optionality (which would conflict with the schema). In fact I have just written a defect report for OOXML on this very topic :-)
>
> So, in sum, I don't believe passive voicing is necessarily a problem when it is supported by unambiguous rules expressed in a schema (but in other contexts it is, typically, not acceptable).

I would want to run example 2 through my ambiguity checker a few
times, but I think you've caught the essence of the way I'm looking at
it.

The problem I see is in the semantics. As presently stated in the ODF
1.1 conformance section, conforming implementations must read valid
input and they must write valid output but the spec doesn't say much
at all about what happens betwixt reading and writing valid documents.
(I'll leave aside the spec's treatment of foreign elements and
attributes for sake of brevity).

Let's try adding one more attribute to your example 1.

[ex 4] The <a> element represents a hyperlink. Its href attribute is
used to specify a URI reference which conforms to RFC blah blah. Its
name attribute is used to specify a hyperlink anchor that conforms to
RFC blah blah.

How might we then brand as non-conformant an implementation that
ignores the semantics and uses the name attribute to house URIs and
the href attribute to enclose the anchor names? Or an implementation
that uses the <A> element and its attributes to read and write
footnotes and their calls? Don't we still have input and output.that
is valid against our over-simplified schema?

But don't we also have an interoperability mess?

 But the point I'm striving toward here is that if one assumes valid
valid input and output, it's what happens between read and write that
will make or break the round trip between implementations. The
semantics matter, the preservation of markup matters, a whole host of
implementation behaviors need to be specified with active voice,
imperative SHALL and SHALL NOT clauses.

And if there is a way to work SHALL or SHALL NOT into a passive voice
clause, I haven't imagined it yet. The passive voice and imperative
mood simply don't mix well in the same clause. Cf.,
<http://en.wikipedia.org/wiki/Imperative_(grammar)#Morphology> ("The
English imperative is formed simply by using the bare infinitive form
of the verb. Be is the only verb whose infinitive form is in [sic]
different from the second-person present indicative form. The subject
of the sentence can only be you (the second person)").

The way a lot of this gets handled in every XML standard I've looked
at other than those that have been through the JTC 1 wringer is the
incorporation by reference of RFC 2119 requirement keyword definitions
rather than the ISO/IEC Directives Part 2 Annex H definitions. In the
latter, MAY is given its common and ordinary meaning of "permission."
But under RFC 2119, every occurrence of MAY and OPTIONAL is bounded by
two mandatory interoperability requirements:

"MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional.  One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same item.

"An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality.

"In the same vein an implementation which does include a particular
option MUST be prepared to interoperate with another implementation
which does not include the option (except, of course, for the feature
the option provides.)"

(Broken into separate paragraphs for legibility.)

You still need to write MAY or OPTIONAL clauses rather than merely
informative text, but in each occurrence of the terms there is a
conformance requirement in the way of breaking interoperability by
getting the semantics wrong, trashing valid markup the app doesn't
support, etc.

There are a whole bunch of (all?) ODF implementations that would be
non-conformant had the requirement keyword definitions incorporated by
reference not been switched from RFC 2119 to the ISO/IEC Directives
version betwixt OASIS ODF 1.0 and ISO;/IEC:26300. (Whether it would
still be practical to  implement ODF in an interoperable fashion is a
whole 'nuther matter. The spec simply wasn't ready for standardization
and still is not.)

But the ISO/IEC Directives seem to be insistent that its definitions
be used despite the tension introduced between JTC 1 standards and W3C
and IETF standards. [1] So it seems a choice between flouting the
ISO/IEC Directives to restore the RFC definitions or going through the
long slog of rewriting the spec using the ISO/IEC definitions, as BSI
originally proposed in its comments on DIS ISO/IEC 26300 that objected
to the presence of the RFC 2119 reference. See my more detailed post
on the need to rewrite to adjust for the disappearance of the ODF
interoperability requirements at
<http://lists.oasis-open.org/archives/office-comment/200903/msg00129.html>.)

 (I'd like to see keyword definitions more appropriate to the IT
sector added to the next version of JTC 1 Directives. The ISO/IEC
Directives definitions are a blunderbuss for international standards
of all kinds. It's an SDO/SSO harmony issue that demonstrably can
result in debacles like nearly all interoperability requirements being
removed from the ODF spec at JTC 1.)

But to summarize, I don't see syntactic conformance requirements as a
substitute for semantic conformance requirements.  (I'm not suggesting
that your caveat was insubstantial.)  In my mind, a complementary
blend of both is necessary not only to read and write valid documents
but also for their processing in an interoperable fashion betwixt read
and write.

But I'm all ears for your thoughts on the dimension of the perceived
problem I've injected.

Best regards,

Paul.

-- 
Universal Interoperability Council
<http:www.universal-interop-council.org>


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