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