From owner-incits-v1@incits-v1.org Wed May 30 05:57:55 2007 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Date: Wed, 30 May 2007 08:56:51 -0400 From: "Mason, James David (MXM)" Subject: RE: INCITS-V1: Behavior, Semantics and Syntax In-reply-to: <465D595A.2000500@durusau.net> Sender: owner-incits-v1@incits-v1.org To: incits-v1@incits-v1.org Reply-to: incits-v1@incits-v1.org X-MIMEOLE: Produced By Microsoft Exchange V6.5 X-MIME-Autoconverted: from quoted-printable to 8bit by midtown.nycx.com id l4UCuup3012112 Content-class: urn:content-classes:message Thread-topic: INCITS-V1: Behavior, Semantics and Syntax Thread-index: AceiqfSg29cjlUSPQMa3gJypauM4lwAChAFQ X-PMX-Version: 5.2.0.264296 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 30 May 2007 12:56:53.0828 (UTC) FILETIME=[FF3E7040:01C7A2B9] I strongly second Patrick: There are vast pitfalls in standardizing only syntax; indeed, I would say that a standard that deals only in syntax and not in semantics is outside the scope of SC34. We've been down this path before, in the 1980s and 90s, and we really don't need to relearn what was established back then. SC34 and its predecessors began with efforts to do something with generic markkup. The result, SGML, creates a framework for building languages. The primary content of ISO/IEC 8879 is indeed syntax, both of the framework and of the resulting languages. Because we were under (mostly external) pressure to write as short a standard as possible, 8879 leaves something to be desired in discussing the semantic implications of language creation. We quickly found this was an error for the practical user of the standard, and Charles Goldfarb's "The SGML Handbook", which was an annotated edition of the standard, was a result. The book was so successful that after its publication almost everyone bought it rather than the bare standard available from ISO. The next thing we learned was that markup languages (that is to say applications) created from SGML were anything but automatically self documenting. In that sense they're no better and in many cases even worse than the products of conventional programming languages like C and FORTRAN: You can trace the logic of a programming language, but even if you try build a tree of potential document structures from a DTD or schema, there are usually so many options that you quickly get lost. Although best practices suggest using "self-documenting" element names, it's hard to guess in many cases what was in the mind of the schema writer. I've been reading and writing DTDs for a quarter of a century, and yet I'm frequently baffled when I see some new serving of "tag soup." It was because syntactic conformance is so often useless that the SGML team took off and created DSSSL: that standard gives at least one way of defining the semantics of a schema, its application to presentation. DSSSL, of course, gave birth to XPath, XSLT, XSL-FO, and other standards that emphasize doing something besides syntactic validation to SGML/XML documents. We learned this lesson again with HyTime and Topic Maps. HyTime was a tremendously powerful set of tools for doing hyperlinking, synchronization, and some neat syntactic things, but it was almost tool flexible. So a group set out to develop best practices for using it. The result was Topic Maps, with DocBook as a spin-off. And now SC34 is revising Topic Maps to clarify, among other things, the semantics of the standard. Even a schema as simple as HTML can be used in so many ways that there's a whole industry out there writing books and giving classes on how to use it. The current proposal is so long and so complex that it takes thousands of pages to document its semantics. I don't enjoy wading through that, but if I just had a schema to provide syntactic conformance, I'd simply declare it wasn't a fit subject for standardization. Having frequently had to deal with the HTML and XML put out by previous versions of Microsoft Office, often coming to a "what the heck are they doing?" point, I'm glad to get the documentation, cumbersome as it is. I still have major problems with the current project in terms of its stated scope and its construction as a piece of writing, but I have hopes that those may be fixed to make it a sutitable candidate for standardization. If it were only a project for syntactic conformance to a schema, I'd say it was totally inappropriate for standardization in SC34 or anywhere else in JTC1. (To be fair, I would say the same thing about ODF. I'm currently howling loudly about some of the documents in the OASIS committee, but only about how they're structured, not about the need for semantic documentation.) Jim Mason -----Original Message----- From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@incits-v1.org] On Behalf Of Patrick Durusau Sent: Wednesday, May 30, 2007 7:01 AM To: incits-v1@incits-v1.org Subject: INCITS-V1: Behavior, Semantics and Syntax Greetings! Tom Ngo mentioned yesterday his interest in DIS 29500 not specifying behavior or semantics. I find that deeply troubling and I would like to explore that issue in greater depth before our next meeting. I concede at the outset that being free to ignore the semantics of a markup standard certainly makes it easier for unanticipated uses to occur in the future and to still claim conformance to the "syntax" of the standard. But, let's consider a standard that isn't before us now as a neutral example. Consider UBL for instance. Certainly UBL defines a syntax, but it also defines semantics. And conforming UBL applications honor both. As Ken Holman notes in "Practical Universal Business Language Deployment": "...using an agreed-upon vocabulary ensures that all users of the XML can identify the same information items usng the agreed-upon labels..." When Ken uses the term "vocabulary" I read "semantics." That is to say that using any UBL conformant application, when it encounters the same UBL vocabulary item, not only does the application recognize the syntax but the semantics of that term. Hence, one has interoperability between UBL conformant applicatons. Contrast that with with syntactic but not semantic conformance. Sure, my UBL-syntactic conformant application can process the syntax but the semantics of what it is processing may be treated in such a way as to give me a completely different result from some other UBL-syntactic conformant application. I don't think that is how European governments are using UBL to save $millions of dollars every year from UBL. I freely admit that I have written markup standards (particularly for Bible encoding) where it would have been nice to duck the semantic issues and simply leave that up to the user. Would make writing standards in contentious domains a lot easier. But, the downside is a loss of interoperability between applications. Or to put it another way, interoperability requires both syntactic and semantic conformance. If in the future we want some other semantics, then we have to write another standard to reflect the new semantics. Is there any disagreement that not requiring semantic conformance diminishes interoperability? (Whether that is dispositive is a separate question. My goal here is to see how close or far apart on this issue.) Hope everyone is having a great day! Patrick -- Patrick Durusau Patrick@Durusau.net Chair, V1 - Text Processing: Office and Publishing Systems Interface Co-Editor, ISO 13250, Topic Maps -- Reference Model Member, Text Encoding Initiative Board of Directors, 2003-2005 Topic Maps: Human, not artificial, intelligence at work!