Re: Input spec: status update

Another approach:

The previous version I sent out had a config file with 169 lines, one 
for each node. I had to manually (read: error-prone) enter on each line 
the data collection intent. Even more error-prone would be adjusting to 
a new drop of the XPath files that for whatever reason added or removed 
things.

Here's another possible approach, based on rules. The first string 
attempts to match on each leaf node (here leaves include things like ) 
The second string is the data collection intent to apply. In a conflict, 
last wins. The following 23 rules encode the same information as the 169 
lines before, and would probably keep working in the face of minor 
additions or removals to the XPath files in subsequent releases.

    rule("ID", "stringinput")
    rule("Code", "stringinput")
    rule("Indicator", "stringinput")
    rule("Name", "stringinput")
    rule("Reason", "stringinput")
    rule("BuildingNumber", "stringinput") # not a bug -- really string
    rule("Mail", "stringinput")
    rule("Telephone", "stringinput")
    rule("Telefax", "stringinput")
    rule("Zone", "stringinput")
    rule("Description", "stringinput")
    rule("Line", "stringinput")
    rule("Terms", "stringinput")
    rule("Country", "stringinput")
    rule("Note", "textarea")
    rule("Date", "dateinput")
    rule("DateTime", "datetimeinput")
    rule("Quantity", "numberinput")
    rule("Numeric", "numberinput")
    rule("GUID", "hidden")
    rule("Amount", "decimalinput")
    rule("@", "hidden")
    rule("/", "group")

This also has the nice property of documenting things internally. -m

-- 
  Available for consulting. XForms, web forms, information overload.
  Micah Dubinko                           mailto:
  Brain Attic, L.L.C.                        http://brainattic.info
  Yahoo IM: mdubinko                                +1 623 298 5172
  Learn XForms today: http://xformsinstitute.com