Re: [ubl-hisc] Examploforms - technology-neutral formdescription

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Thanks to Micah for this encouraging project. It'd be ideal if it might become
a standard but I'm not aware of anything that might already be more standard
or suitable for storing presentation-related data in the xml instance or
schema to which it relates. 

I quite like the idea - perhaps for use with the ubl lite example instances. 
Not to discount using XPaths too though.

It's just that this combines the XML and the formatting information.
I might prefer a way to do this with the Schemas if it weren't for the
desirability of starting with a subset of the Schema - and an example instance
may be as good a way to do this as a set of XPaths. Perhaps if Ken
would adapt his tool for generating XPaths to be able to start with an
examploform or alternatively the tool could start with an examplotron
'schema' and both XPaths and examploform be generated from this.

Again another way would be to start with example instances and generate
XPaths from these but I guess this would be tricky without a clear way to
denote cardinality of repeating elements - for this a combination of instance
and Schema with a schema-aware transformer (Saxon 8?) might help. And
then there would still need to be the storage of the formatting instructions
such that a stylesheet could get at the formatting rules. I'm not sure our
docbook xml would be better than examploform for that and do we have
any other option of a well thought out format for holding such data?

Still, keeping to as few ways as possible seems sensible so maybe the 
optimal way, with least steps, would be to use Micah's examlpoform.
That way both the starting point for XPaths and the storage of formatting
data can be kept together in one place. Sounds neat to me. There were 
all those discussions about this back in Montreal I remember but I don't think
there was a clear design for the 'adjunct file' as it was called then. This seems
to provide for that and has the promise of the design possibly succeeding
as a possible standard in the making or at least becoming established and
well-known.

I guess folk would prefer to see the use of something already established 
but we don't seem to have it, that is we have XPaths, yes, but not the 
means to store the formatting data with them apart from in our docbook 
xml and formatted docbook specs. (Was there ever a design developed
for 'adjucnt files'? I wonder if this design would extend to cover codelists.) 

This at least adds the means to have something from which the xslt can 
generate forms, and with just the one starting point needed.

Very grateful to Micah

All the best

Steve


>>> Micah Dubinko <micah@dubinko.info> 13/12/04 17:12:38 >>>
Well, I misunderstood Stephen's statements by about 180 degrees, and for 
that I apologize. :) To make up for it, I have something else to offer.

I told Ken last week that I couldn't think of any existing 
technology-neutral ways to specify input--but I forgot about my own project!

http://examploforms.org 

It builds on the basic ideas of Rick Jelliffe's Schematron and Eric van 
der Vlist's Examplotron. The basic data structure is just a piece of XML 
representing the skeleton that gets fleshed out with form data, adding 
form-specific annotations like labels, indications of calculations, and 
so on.

My current (experimental) implementation is an XSLT that transforms 
examploforms into XForms, but it would be just as easy to go to any 
other form technology.

Anyway, worth a look, if for nothing else as a starting point for 
discussions.

.micah


-- 
  Available for consulting. XForms, web forms, information overload.
  Micah Dubinko                           mailto:micah@dubinko.info 
  Brain Attic, L.L.C.                        http://brainattic.info 
  Yahoo IM: mdubinko
  Learn XForms today: http://xformsinstitute.com