Re: Combining float/string to specify value/units

[Steve Rosenberry <steve.rosenberry@verizon.net>]

To summarize what I've learned for all who care:

Kohsuke Kawaguchi suggests that all primitive and built-in types should
be specified in the spec using BNF.  To admit the truth, I don't know
what BNF is an acronym for.  Based upon what Thomas Passin said in a
previous message, I'll assume its the notation used in declaring the XML
Schema regular expression syntax.  I'm also going to assume that BNF
provides a mathmatically precise way of declaring this syntax as opposed
to something the lay person (myself) can more instinctively recognize
and understand.  Thankfully, the Primer has a table of examples which I
found much more understandable.  While I can see where a BNF
specification eliminates some ambiguities in the spec, I'm not ready to
support anything that makes the spec even less readable for someone like
myself.

Unfortunately, the mechanism suggested by both Rick Jelliffe and Eddie
Robertsson built upon a list of unions of floats and enumerated strings
does not validate in XML Spy 3.5.  I can specify multiple float values
in the list ("1.0 2.0 3.0") or multiple units measurements ("msecs %"),
but XML Spy will not allow a mix of a float value with a units string
("25 msecs").  Since both gentlemen arrived at the same solution and
pointed out the same drawbacks to it (less than absolutely precise
validation), it may very well be a problem with the XML Spy validator.

But Rick also makes the point that simple string-pattern matching used
by itself to achieve my desired result eliminates the type checking of
attribute values against any inclusivity and exclusivity facets in a
type-specific manner.  (I paraphrased and possibly oversimplified, so I
hope I'm still on point with him.)

So back to my original problem of specifying a single attribute that
includes what in many cases should probably either be split into two
attributes (value and units) or given as element content -- the current
spec has no nice neat method of doing this.  My goal with my particular
application is to define a simplified language syntax that many people
without formal training can easily understand and replicate by example
without losing the datatyping brought to the table by XML Schema.

For example, I could specify the following given the current spec and
achieve full type checking and inclusivity/exclusivity functionality (AV
is an abbreviation for Audio/Video, one of the core systems controlled
by any good home automation system):

  <AVCommand volume="25" units="%"/>

or with the enhancements to regular expression parsing suggested below I
could specify:

  <AVCommand volume="25%"/>

A subtle difference, certainly, but the second example is easier for
someone without any formal XML training to understand.  My definition of
easier to understand is whether or not someone will ask me, "How come
the '%' has to be separated from the value?"  In the first case they
will; in the second, it never occurs to them that it would be done any
differently. 

Without getting into a discussion of all the possible potholes one can
fall into especially with regards to unit conversions before applying
inclusivity/exclusivity facets, the question remains is there merit to
allowing datatype's to be specified as an atom in a regular expression?

I suggest something along the lines of the Unicode Database encoding,
e.g. \p{Lu} specifies all upper case letters.  For discussion purposes,
let's assume \x{datatype_name} is the syntax.  Now I could specify what
I need for my end users using the following regular expression:

<xsd:simpleType name="Percentage">
    <xsd:restriction base="xsd:string">
        <xsd:pattern value="\x{xsd:float}%" />
    </xsd:restriction>
</xsd:simpleType>

<xsd:element name="AVCommand">
  <xsd:complexType>
    <xsd:attribute name="volume">
       <xsd:simpleType>
          <xsd:restriction base="Percentage">
            <xsd:minInclusive value="0%" />
            <xsd:maxInclusive value="100%" />
          </xsd:restriction>
       </xsd:simpleType>
    </xsd:attribute>
  </xsd:complexType>
</xsd:element>

resulting in the simplified XML that my end users could generate:

  <AVCommand volume="25%"/>

and can be fully validated for a float value within the inclusive range
and that the required units measurement is in place.  Surely this single
example of working with a value and its associated unit of measure is
not the only case that can benefit from such syntax.


My 2 cents -- actually given the length it might be a dime's worth.  :)


-- 
Steve Rosenberry
Sr. Partner

Electronic Solutions Company -- For the Home of Integration
http://ElectronicSolutionsCo.com

http://BetterGoBids.com -- The Premier GoTo Bid Management Tool

(610) 670-1710