Re: miscellaneous comments was Re: Model draft

"Joel M. Halpern" <> Wed, 16 January 2008 22:46 UTC

Message-Id: <WED.16.JAN.2008.174626.0500.>
Date: Wed, 16 Jan 2008 17:46:26 -0500
From: "Joel M. Halpern" <>
Subject: Re: miscellaneous comments was Re: Model draft
Comments: To: "tom.petch" <>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit

I realized trying to make corrections to the document, that there are
two different issues that get confused in the discussion below.

>>> 4.7.3.  <outputPorts> Element to Define LFB Outputs
>>>    This is indicated by a "yes" value
>>>    (the default value is "no").
>>> **+ The XML has default of 0 - I see no indication which is yes and which
> no;
>>> some XML users define a truthValue, of yes or no.
>> Not sure what you are asking for.  The attribute definition says that
>> the attribute is optional and has a default of "no".  Folks have run
>> this through XML vereifiers and it seems okay.
> What I am looking at in the Schema is
>  <xsd:simpleType name="booleanType">
>         <xsd:restriction base="xsd:string">
>           <xsd:enumeration value="0"/>
>           <xsd:enumeration value="1"/>
>         </xsd:restriction>
>       </xsd:simpleType>
> from which I cannot tell whether you intend 0 means true or 0 means false, so
> syntactically valid but semantically ambiguous to me.  I am used to both in
> other languages and prefer the XML-Schema approach which allows, to quote
> Lexical representation
> An instance of a datatype that is defined as .boolean. can have the following
> legal literals {true, false, 1, 0}.
> so using true and false is - to me - clearer.

The two cases are the value of boolean XML attributes, for example the
"group" attribute on the <outputPort> XML element.  We are inconsistent
in the document about the values we for these.  As these are XML, for
use by an XML parser, they should be defined as xsd:boolean, and should
use true and false in all references.
The actual "booleanType" is a definition of a type for use as a value
type of a ForCES component.  It is restricted to the values 0 and 1, and
will be transported in the protocol as the single bit values 0 and 1
(typically in a byte or larger, but that is a different issue.)
My guess is that the reason things were passing the parser is that many
parsers probably don't get the enumeration restriction enforcement right.
So the booleanType declaration does not need a true / false explanation.
  But the groups reference (for input and output ports) needs to be true
/ false, not yes / no.