[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-hisc] Examploforms - technology-neutral formdescription
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]