Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Taking Data Validation to a Dynamic Level : Page 2

A declarative schema works well with XML data streams in a distributed context, where validation should be more functional and use a processing model that evolves beyond a single, static document for XML content.

Associative Arrays
If you take a look at a traditional HTML page, in general the <select> element works on the assumption that you are using an associative array:

colors = {rd : 'red', or : 'orange', ye : 'yellow', gn : 'green', bu : 'blue', vi : 'violet'} <select value="rd" name="colorkey"> <option value="rd">red</option> <option value="or">orange</option> <option value="ye">yellow</option> <option value="gn">green</option> <option value="bu">blue</option> <option value="vi">violet</option> </select>

The content within each option text block is a "label" (the right side of an array item), while the value attribute holds the "name" of each item. Significantly, when an item is selected, and while the label for that item is displayed in the drop-down list, the value of that control will be the associated left-hand name of the option. A similar expression holds for XForms, though the relationship is a little more explicitly defined:

<xf:select1 ref="colorkey"> <xf:item> <xf:label>red</xf:label> <xf:value>rd</xf:value> </xf:item> </xf:select1>

These concepts are of course fundamental to most computer languages, but things get a little more complex when one considers a slightly different model in XForms:

<xf:model id="datamodel"> <xf:instance id="data"> <data> <colorkey>rd</colorkey> </data> </xf:instance> <xf:instance id="colors"> <colors> <color name="rd" label="red"/> <color name="or" label="orange"/> <color name="ye" label="yellow"/> <color name="gn" label="green"/> <color name="bu" label="blue"/> <color name="vi" label="violet"/> </colors> </xf:instance> </xf:model> <xf:select1 ref="colorkey"> <xf:itemset nodeset="instance('colors')//color"> <xf:label ref="@label"/> <xf:value ref="@name"/> </xf:item> </xf:select1>

In this case the associative array (defined here as the names and labels on a color element) is contained in a data instance that is unique from the selection control. This location is a little strange if you're coming from HTML—where the control holds the relevant array—but it's pretty normal if you're working with XForms content. In XForms content the underlying assumption is that the control is providing only a view on an existing data structure; the associated array acts much like a schema defining the constraints that determine which values are valid for that particular data property.

So far, so good; schema through an enumerated list is a pretty typical use of schemas (XSD schemas in particular). However, take the next step, which is shifting that particular constraint list so that it comes from an external XML file:

<xf:model id="datamodel"> <xf:instance id="data"> <data> <colorkey>rd</colorkey> </data> </xf:instance> <xf:instance id="colors" src="colors.xml"/> </xf:model> <xf:select1 ref="colorkey"> <xf:itemset nodeset="instance('colors')//color"> <xf:label ref="@label"/> <xf:value ref="@name"/> </xf:item> </xf:select1>

Conceptually, this approach isn't all that much of a jump; although, notice what's occurring in the bigger picture. If you look at this list of colors as being part of a schema, then that schema just became distributed—at least part of the schema exists outside of the scope of the rest of the schema. Again, this approach isn't all that unusual because most schemas include some form of modularization aspect anyway—modularization that breaks up the schemas into distributed pieces. The schema's beginning to drift into the network, but it's still constrained and static.

Or is it? Consider one additional step:

>xf:model id="datamodel"> <xf:instance id="data"> <data> <colorkey>rd</colorkey> </data> </xf:instance> <xf:instance id="colors" src="colors.xq"/> </xf:model> <xf:select1 ref="colorkey"> <xf:itemset nodeset="instance('colors')//color"> <xf:label ref="@label"/> <xf:value ref="@name"/> </xf:item> </xf:select1>

In this case the source changed from being an XML document to being the result of a REST-invoked XQuery (substitute your own favorite server language here; the concepts are just as valid). Yet at the same time, something profound happens. The query assumes that some dynamic process has just taken place, which in turn means that the enumerations that the particular model can hold are no longer static. For instance, suppose that colors.xq reached into a Crayola crayon box (the one with 10 gazillion colors in it) and pulled out a random set of, say, 12 colors. Moreover, every day or so about 5 percent of the colors in the initial set are retired, and an equivalent amount is added. In essence, while you have an enumerated set of colors, you no longer have a static definition of that set—you cannot model it in XSD.

The example may seem contrived, but it is exactly the same problem as the Nordstrom's store problem described previously, and is in fact becoming typical in building web applications. You could argue at this point that the results should be just a blank text field and an unconstrained set, but that's not the case. The set is known and at any point can be validated, but the set is also dynamic—such validation is a function of time. The color may be available, the store may be active and not yet closed, but the validation state has now acquired time as a parameter. The world works this way, and to ignore this fact for the sake of convenience will result in building models (and applications) that fail in subtle but important ways.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date