From owner-incits-v1@incits-v1.org Wed May 30 07:01:28 2007 MIME-Version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_4mpihGLQINNjnFgScZKhYQ)" Date: Wed, 30 May 2007 08:00:00 -0600 From: Tom Ngo 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 Content-class: urn:content-classes:message Thread-topic: INCITS-V1: Behavior, Semantics and Syntax Thread-index: AceiqebRL+gwKfDQS76rkCcdpF/4MgADVBeA X-PMX-Version: 5.2.0.264296 X-MS-Has-Attach: X-MS-TNEF-Correlator: This is a multi-part message in MIME format. --Boundary_(ID_4mpihGLQINNjnFgScZKhYQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT [this email is in HTML - hope that's ok] Patrick, I think you're absolutely right. For whatever reason, the words I said on our phone conference yesterday came out backwards. Here is my position, which is the result of extensive discussion with a few others on the Ecma TC45 committee. I especially tip my hat to Adam Farquhar (British Library) and Philip Mansfield (Apple) for some very illuminating insights - pun entirely unintended. * Syntax: Yes, DIS 29500 specifies syntax. By the way, most syntax is easy for a machine to validate. Some syntax (most "additional syntax constraints") is harder for a machine to validate, but should be easy for a human to validate unambiguously. * Semantics: Yes, DIS 29500 specifies semantics. For example, the w:b tag in a WordProcessingML run denotes the bold format, and an implementation is not free to ignore this meaning while still claiming conformance. By the way, it's usually very hard for a machine to validate semantics - but reasonable human beings can usually agree quickly on whether an implementation has respected the required semantics. So far, I think we are on the same page; I believe your UBL example lines up exactly with these statements. Now let's talk about behavior and see if we still align. * Behavior: No, DIS 29500 does not constrain behavior except where directly implied by semantics. By the way, the judgment as to whether a particular behavior respects the underlying semantics of the format can sometimes be a matter of opinion, but in most real-world cases, reasonable human beings can agree quickly. * Behavior Example #1: someone creates a WordProcessingML viewer that renders rich text, but decides to hide all text that falls inside a run that contains in its run properties. That viewer is non-conforming because it violates the semantics of the w:b tag. * Behavior Example #2: someone creates a WordProcessingML viewer for the blind that renders text as speech, and raises its voice whenever it encounters a such a run. This is reasonable behavior for bold text; users of this software do not feel jilted. We have protected them by allowing the concept of Conformance to extend to behaviors unique to a text-to-speech reader, while insisting that the standard does specify semantics. I hesitate to find an example in the UBL world since I'm an ignoramus among the erudite, but I'm guessing that it constrains the semantics of a purchase order (an order is an order is an order) but does not constrain the behavior of an application that encounters an order (which could fulfill the order, print it to a report, or even transform it to represent a larger order quantity while remaining clearly within the specified semantics of the Order tag). Your thoughts? Tom -----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 5: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! --Boundary_(ID_4mpihGLQINNjnFgScZKhYQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable RE: INCITS-V1: Behavior, Semantics and Syntax

[this email is in HTML hope thats ok]

Patrick, I = think you're absolutely right. For whatever reason, the words I said on = our phone conference yesterday came out backwards. Here is my position, = which is the result of extensive discussion with a few others on the Ecma = TC45 committee. I especially tip my hat to Adam Farquhar (British = Library) and = Philip Mansfield (Apple) for some very illuminating insights pun entirely = unintended.

·       Syntax: Yes, DIS 29500 specifies syntax. By = the way, most syntax is easy for a machine to validate. Some syntax = (most additional syntax constraints) is harder for a machine to = validate, but should be easy for a human to validate = unambiguously.

·       Semantics: Yes, DIS 29500 specifies semantics. For = example, the w:b tag in a WordProcessingML run denotes the bold format, and = an implementation is not free to ignore this meaning while still = claiming conformance. By the way, its usually very hard for a machine to validate = semantics but reasonable human beings can usually agree quickly on = whether an implementation has respected the required = semantics.

So far, I think = we are on the same page; I believe your UBL example lines up exactly with these = statements. = Now lets talk about behavior and see if we = still align. 

·       Behavior: No, DIS 29500 does not constrain behavior except = where directly = implied by semantics. By the way, the judgment as to whether a particular behavior = respects the underlying semantics of the format can sometimes be a = matter of opinion, but in most real-world cases, reasonable human beings = can agree quickly.

·       Behavior = Example #1: someone creates a = WordProcessingML viewer that renders rich text, but = decides to = hide all text that falls inside a run that contains <w:b/> in its run = properties. = That viewer is non-conforming because it violates the semantics of the w:b tag. =

·       Behavior = Example #2: someone creates a = WordProcessingML viewer for the blind that renders = text as = speech, and raises its voice whenever it encounters a such a = run. This is reasonable behavior for bold text; users of = this software do not feel jilted. We have protected them = by allowing = the concept of Conformance to extend to behaviors unique to a = text-to-speech reader, while insisting that the standard does specify = semantics.

I hesitate to = find an example in the UBL world since Im an ignoramus among the = erudite, but = Im guessing that = it constrains the semantics of a purchase order = (an order is an order is an order) but does not constrain the behavior = of an application that encounters an order (which could fulfill the = order, print = it to a report, or even transform it to represent a larger order quantity while = remaining clearly within the specified semantics of the Order = tag).

Your = thoughts?

Tom

-----Original = Message-----
From: owner-incits-v1@incits-v1.org [mailto:owner-incits-v1@inci= ts-v1.org] On Behalf Of Patrick Durusau
Sent: Wednesday, May 30, 2007 5: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!

= --Boundary_(ID_4mpihGLQINNjnFgScZKhYQ)--