Re: miscellaneous comments was Re: Model draft
"Joel M. Halpern" <joel@stevecrocker.com> 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" <joel@stevecrocker.com>
Subject: Re: miscellaneous comments was Re: Model draft
Comments: To: "tom.petch" <cfinss@dial.pipex.com>
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 > > 3.2.2.1 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. Joel
- Re: miscellaneous comments was Re: Model draft Joel M. Halpern
- Re: miscellaneous comments was Re: Model draft tom.petch
- Re: miscellaneous comments was Re: Model draft Joel M. Halpern
- Re: miscellaneous comments was Re: Model draft tom.petch
- Re: miscellaneous comments was Re: Model draft Joel M. Halpern
- miscellaneous comments was Re: Model draft tom.petch