Re: [ubl-hisc] Minutes for 2006-02-21 HISC teleconferences

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

At 2006-02-22 08:53 -0500, Bryan Rasmussen wrote:
> >Ken: Can resources from Denmark create and post sample instances for
> >the UBL 2.0 version of UBL 1.0 documents and the above prioritized
> >documents?
>
>I've been basically using the small business subset examples, changing the
>content to be somewhat useful (since the SBS examples were generated via
>XMLSPY).

Great ... when you have a representative set, could you please post them?

> >3) Input specification status.
>I'm hoping to have it done by next weeks meeting, or at least have a good
>level of progress.

Well done.

>Just to make sure that my understanding is correct though
>because it just struck me that what I've understood my task to be may have
>been misunderstood, by shell inputs are we in aggreement that I am producing
>displays of what the forms will look like when they follow the formatting
>specifications laid out in the formatting specs doc (minus data), correct?

You tell us ... what *is* an input formatting specification?

For output it is fairly simple, just a mapping of UBL XPath addresses 
to locations in a given (hopefully standardized) layout.  All the 
data is self-contained and the output presentation isn't *allowed* to 
change any of the numbers.

For input I could imagine it would be more detailed, but it isn't 
something I'm intimate with so I wouldn't know what to recommend.

At the least I would think there has to be a mapping of XPath 
addresses to input form controls.

Does XForms include presentation?  I thought it was more 
abstract.  Would the mapping be to the class of form control, or to a 
particular presentation choice for a form control?

Are there calculations that need to be specified?  Tax 
totals?  Amount totals?  Which XPath addresses participate in the calculations?

Are there input lexical constraints that need to be documented for 
each field?  "this field is numeric", "this field is alphanumeric", 
"this field is currency", etc.

If you were to mimic what I did with the output formatting 
specifications, the embellished DocBook documents would have 
sufficient information embedded in the XML that a transformation 
produces a pure DocBook instance for publishing purposes, and a 
mechanical extraction with another stylesheet produces information 
suitable for processing into XForms specifications or some other 
representation.

The goal of the output specifications is "collect, distill and 
publish enough information about UBL that an implementer can satisfy 
a printing requirement without having to have been a member of the 
UBL TC to know what is important and what isn't, thus relying on the 
subject matter expertise within the technical committee to reveal 
that which is necessary to address."

I would extrapolate, then, that the goal of the input specifications 
is "collect, distill and publish enough information about UBL that an 
implementer can satisfy a requirement to accept input from human 
interaction with forms to create a UBL instance without having to 
have been a member of the UBL TC to know what is important and what 
isn't, thus relying on the subject matter expertise within the 
technical committee to reveal that which is necessary to address."

I would think that what to then *do* with the accepted input 
information is out of scope ... one implementer might offer to send 
an email, another might load up a database, yet another might create 
a disk file, finally one might trigger a workflow process.  I don't 
believe any of that is in the scope of distilling what is important 
in UBL to someone not a part of UBL ... *that* is the expertise HISC 
is using to add value to the UBL package to help UBL become more implementable.

Not every vendor is going to have the time or energy or money to 
participate in the UBL development process, but by HISC doing the 
heavy lifting in the area of exposing what would be important to 
vendors, then vendors can implement the HISC specifications knowing 
the specifications have been approved by the TC so an implementation 
of the specifications should be acceptable to the TC and to users of 
UBL in general.

That's how I see it, anyway ... has your perspective been different?

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

--
Upcoming XSLT/XSL-FO hands-on courses: Washington,DC 2006-03-13/17
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 Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal