[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Combining float/string to specify value/units
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|