[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: "Strictly conforming" is not related to "interoperable"
[Note: After writing this up, I realized that it might be sort of old news or "preliminary knowledge required". Perhaps though it can serve to help others that, like me, are trying to get a better grip of these topics: eg, strictly conforming vs interoperability.] This topic is an extension of these two threads: http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00127.html http://lists.oasis-open.org/archives/oiic-formation-discuss/200806/msg00265.html I'd like to add perspective to "strictly conforming" and "interoperable". These sound to me like they might be related, but I'll draw some parallels to the C programming language to help make some things clearer (at least the exercise was useful to me). First, let me apologize for making it sound as if what I was talking about was obvious, "clear", etc. It's probably fair to say that I spend a lot more time thinking about the violation of a standard vs. the following of it, at least when it comes to ODF and OOXML. In addition, I've been exposed to a number of varied standards ("painfully" reading the text in various cases), so many people that might be on this list, to say the least, might not have these scenarios I've been mentioning (see links above) at the very forefront of their consciousness as I do. Even more foreign might sound these ideas/examples to a typical reader of a light news site or related blog (some of whom might be paying attention to this mailing list, as I myself arrived here via announcements made on groklaw). Here are some thoughts on how "strictly conforming" might compare/contrast within the contexts of ODF vs. C (the programming language). Let me note that ODF can be described as being a declarative language vs. C a functional language. This may be important (eg) in terms of us being lulled into missing some commonalities or differences. C defines standard keywords. These include the primitives, like "while", "for", "if", "else".., which are used to construct the functionality of the "document" (ie, of the program). ODF defines some basic terms as well, for example, various XML elements such as the one used to delimit paragraphs (text:p). In C, functions might be considered how the language is extended. Well, you could also extend the language by adding keywords, but these likely would be syntactic sugar to what could otherwise be expressed as a function, using the existing keywords (turing complete, etc). It's important to note that the former method (function creation) is expected, is necessary, and so is not considered an "extension" of the language. Alternatively, creating new keywords would be considered an extension to the extent you would no longer be "strictly conforming" (or, for that matter, would also no longer be "conforming", as defined by C). Contrast this to ODF, where specifically extensions are defined as the addition of distinctly named element nodes, and as long as these use (are qualified with) a different namespace than those used in the standard, you can still maintain "conformance". So how might be draw parallels between these two "document languages"? If C keywords are like the predefined elements in ODF, then would nonstandard C keywords be like ODF foreign element nodes? Or might instead it be C functions that are like ODF foreign element nodes? Neither of these map cleanly. [It's possible the the declarative vs. functional themes lead to unclean mappings, but it's also very possible I just haven't thought this out well enough.] How about data? Would ODF element content (excluding the children elements; ie, only things like the text within text:p .. I forget the technical term for it) map to C string literals? [or maybe even to what are commonly known as variables by C programmers?] In any case, strict conformance is a property used by each of these standards to describe adherence of documents (or applications) to the official structure of these languages [syntax], as well as to some standardized properties that must hold true among the components within a single such document (app) [semantics]. It has little to do with the runtime interactions/characteristics among two or more such "documents" or applications. Let's now look at the noble goal of interoperability. With ODF, on this and related mailing lists, we are trying to tackle this problem, so let's look at what might be an analogous situation to interoperability in C. In C, are programs generally expected to interoperate? Of course not. It makes no sense that my command line utility for substituting text substrings within my website static html webpages is going to interoperate with your graphical program for managing networks... except perhaps within a few scenarios that would be well-defined and narrow in scope (eg, through stdin/out or perhaps through dbus services or some particular sockets, signals, etc, interaction as prescribed by some external standard). So what happens with C "documents" (as well as with those of any other programming language) is that many separate standards get created to deal with specific scenarios where you want interoperability (and even here, notice that standards generally serve to help those that want to interoperate as opposed to creating a checklist or test that would be used to identify those breaking the rules). [With ODF, I suppose we would be (and are) talking about profiles, which might be the equivalent of some family of C related interop standards.] So should ODF be expected to cover a wide range of interoperability criteria while at the same time being the definition of what could be seen as the base language? In any case, how much coverage would we expect to have? .. and how much does it make sense to be able to *certify* "interoperable" applications/documents? My concern is the use of terms like "strictly conforming" within a context to imply interoperability when in fact the two are quite unrelated, at least as "strictly conforming" for ODF is defined today (which would be analogous to the C definition of strictly conforming, which was reasoned above as having nothing to do with the ability of two C programs to *interoperate* at any level whatsoever).