Re: [ubl-hisc] HISC Teleconference 2005-03-01/02

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2005-02-28 22:23 -0700, Micah Dubinko wrote:
>Attached is a slightly more updated version. This is about as far as it 
>goes without connecting the other thread; writing the XSLT/Python or 
>whatever to start generating the spec for each UBL document type.

I'll be interested to see if you decide to follow through with the seeded 
DocBook instance and some post processing.

>     Abstract: Everything a form author needs to know to become productive 
> with
>     UBL.

Precisely!

>   Forms and XML have much in common--in both cases the technology 
> represents a
>   structured exchange of data, as opposed to a "blank page" philosophy of
>   interaction. UBL in particular is an application of XML used to represent
>   strutured business documents. Some work has been done as modeling this with
>   contract semantics, as in
> 
>http://lists.oasis-open.org/archives/legalxml-econtracts/200403/msg00004.html

Can this be cited as a bibliographic reference with the URL down 
below?  While interesting and germane, it isn't (I think) to the immediate 
objective of writing an input specification.

>   Within each document type, UBL defines a large number of XML elements and
>   attributes; generally more than any single document will use. For this 
> reason
>   part of the job of writing forms against UBL is choosing the proper 
> subset to
>   map to form controls. One subset that is gaining traction is the "Small
>   Business Subset" (once known as UBL Lite).

I think we can now dispense with the old name ... if we can't get the 
permission to use it, I'd hate to have it propagated at all and have 
someone else exploit that it was known as this once.

>   For each data item in the Small Business Subset, these input specifications
>   will list the following pieces of information:
>
>   * The "data collection intent" for this item, without giving specific 
> guidance
>   (like "this is a radio button"). Technology-neutral terminology is 
> taken from
>   the W3C XForms specification.
>
>   * The data storage location within the UBL XML, specified as XPath.
>
>   * Whether the data item may store a computed value, and if so, the 
> sources and
>   expression (again in XPath) used.

Lookin' good!

>   Additionally, for the overall form, the following information will be 
> listed:
>
>   * Overall navigation order, specified as a single bidirectional
>   thread.

"with indications of groups of fields that might make sense if the form 
were split into pieces" (or some such ... so that we can specify the form 
as a whole if the real estate is available, and chop it up if it isn't 
available as in a handheld ... but do it all with the one specification).

>   The XPath details of elements in the SBS were extracted from XML files
>   provided in that package.

Yes ... good to keep it separate ... while we are testing the efficacy of 
the files in HISC you are correct that they will (eventually) become a 
deliverable of SBSC.  Actually, perhaps you could just reference the SBS 
provided in the support materials in the package from the SBSC.

Well done, Micah!

............................ Ken

--
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal