Re: Human Interface Group -UBL

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

Good morning, Bryan and Peter, thanks for your note today.

I hope you don't mind that I've copied this reply to the HISC mail 
list, because I think this needs public discussion by the entire group.

At 2006-01-31 12:55 +0100, Bryan Rasmussen wrote:
>We were just wondering here when the meeting of the Human Interface Group
>will be.

We can probably start as early as next week, though the committee has 
prioritized my code list contributions as higher priority that my 
HISC contributions.

In Ottawa, Zarella modified the formatting specifications of the 
eight document types from UBL 1.0 to be parameterized in such a way 
to promote easier implementation by software supporting basic layout 
components of the UN Layout Key.  Zarella now *owns* the formatting 
specification documents and my contribution is the testing of those 
parameterizations to prove that what she has written accurately 
reflects the desired result.

This parameterization will also greatly improve the ability to 
accommodate new output presentations that follow the UN Layout Key, 
so that as Zarella receives input from others suggesting UN Layout 
Key presentations of the new document types, she can quickly create 
the formatting specifications to be part of the new supplemental UBL 
package.  And I, in turn, can test them to ensure that, as published, 
they accurately reflect the desired result.  Thus, they will be 
sufficient for any implementer to get the desired result.

>Also there are some issues that we should probably put up for
>discussion, these are quickly:
>
>1. Possibility of switching from UN formatting rules for Invoices when
>presentation is web media - I sort of don't think it makes that much sense
>to do formatting after these rules outside of print media.

The formatting specifications are meant to be only examples in the 
supplemental package of ways of presenting the information.  The UN 
Layout Key examples were chosen because of decades of use and 
acceptance of this layout for the printed form.

I acknowledge that for the web medium, the printed layout key is 
neither optimum nor even perhaps apropos, but the web presentation 
was a byproduct of the implementation of the print 
presentation.  Note that the formatting specification itself is the 
mapping of UBL components to the components of a presentation, it 
isn't meant to be the actual implementation of the presentation.

Undoubtedly there could be far more imaginative web presentations of 
the information, yet there aren't a lot of resources and there isn't 
a lot of time.  Leveraging the UN Layout Key PDF presentations into a 
web presentation allows there at least to *be* a web presentation, 
even though it isn't ideal.  Given the limited resources available to 
HISC it is better to have something that might not be best than not 
to have anything at all for the web.

>2. Seperating the original Crane architecture you defined for your
>transformation, i.e. transform to XSL-FO and from there to other display
>formats. At least where HTML is concerned we might expect a lot of
>transformations to take place on the server, in such a case I would prefer
>to provide direct transformation despite the extra work implied.

That objective makes a lot of sense, but the discussion is outside 
the scope of HISC.  Again, and this is a common misconception, 
stylesheets are merely artifacts implementing the formatting 
specifications.  The formatting specifications are meant to be 
examples of how to encapsulate the enabling information needed by 
implementers of human interface products to work with UBL instances.

HISC began when I was tasked with writing stylesheets and found 
insufficient information with which to do so.

All along I've felt very strongly that the role HISC plays is to 
*enable* an implementer to write stylesheet implementations, not to 
actually create implementations of any kind.  To do so may, in fact, 
be construed as bias by those who implement other technologies (both 
proprietary and non-proprietary).  However, by being implementation 
agnostic, implementers can choose however they wish to implement the 
specifications.

The current suite of formatting specifications enable implementers to 
create implementations by enumerating the mappings of UBL information 
items to components of an output presentation.  This allows *any* 
implementation technology to be deployed to take advantage of those 
mappings.  I do not believe that HISC should produce anything other 
than the mappings, and that all HISC energies should be expended 
making the mappings easy to use and as informative as possible.

The supplemental package can then point to as many implementations as 
are known to exist ... fancy or not fancy ... proprietary or 
non-proprietary.  This opens up the opportunity for anyone outside of 
HISC to take the HISC work and create the server-side implementations 
of which you speak.

But to expend HISC energies elsewhere, such as actual 
implementations, I think is inappropriate and a misuse of those energies.

So that Crane's architecture happens to leverage the PDF layout as 
HTML is a decision at Crane to get something out when there exists no 
better HTML-oriented formatting specification published by HISC.  It 
would add yet more demand on the limited resources to introduce into 
the HISC work plan the writing of a parallel set of different 
formatting specifications for web presentation.  If we get the 
resources to do that, great, but given the limited time and that we 
have another 21 layouts to create in order to have a complete suite, 
I doubt we'll find the resources to look at alternative HTML presentations.

>We might also have discussion points a propos OpenOffice, I am basically
>supposing I will produce xsl-filters for import and export, want to make
>sure there is support for that (as opposed to using native Xforms support in
>OO to support mapping to Invoice)
>We might want to define what the functionality of an OpenOffice
>implementation should be.

I've prototyped XSLT import and export filters for precisely this for 
Stephen Green already, though he hasn't seen my results yet.  I'm 
hoping to have something ready in the next couple of days based on 
his prototype OpenOffice form that he posted.  I'll send it to him 
and let him decide to share it with the UBL mail lists or not.  From 
what I've experimented with so far, my objective is to do a simple 
File/Open and File/Save from and to a UBL Invoice using Stephen's 
form as the OpenOffice manifestation of the information.  Thus, you 
don't even need to use Export, just Open/Save.

>Calculation of amounts, etc. ?

A critical component of input forms, I agree ... but totally 
inappropriate for output presentations as all of the information in 
the presentation is, I gather, meant to come from the instance and 
not to be calculated on the fly.  If there were a role in the output 
presentation of such duties, then different implementations might 
have different results (through different errors, miscalculations or 
bad assumptions).  So for output, the only role is the unchanged 
presentation of information found within the instance, without any 
manipulation.

However, on the input side, the critical role it plays is to fill in 
the instance components automatically so that not all fields have to 
be typed in by users.  As such, I would hope to see in any HISC input 
specification the detailing of guidelines to implementers of how such 
calculations should be implemented.

Once again on this input side, the input specification created by the 
limited energies of HISC should *solely* be the guidelines and 
requirements, and not actual implementations, thus enabling 
implementers to create a myriad (hopefully) of implementations 
following those guidelines and requirements.  I have anticipated that 
your efforts in creating input specifications would parallel the 
writing of the output specifications by solely summarizing the 
requirements and guidelines for implementers in the creation of 
implementations of the input specifications.  Finding resources 
outside of HISC to actually implement and test those input 
specifications would be important in order to assess the accuracy and 
completeness of the specifications, but again I would not anticipate 
actual implementations to be part of the HISC deliverables ... 
*pointers* to actual input implementations of course would be part of 
the input specification deliverables.

I hope this clarifies my perspective of the efforts of HISC ... I'm 
anxious to hear if this is resonant with you and other members of 
HISC.  I see our role solely as enablers, not as implementers, and I 
think we should continually focus and re-focus all of our efforts 
asking ourselves if what we are doing is enabling implementations to 
be created (and testing the accuracy of the specifications is part of 
that), and not trying to actually create implementations as part of 
the package.

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

--
Upcoming XSLT/XSL-FO hands-on courses:  Denver,CO March 13-17,2006
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/m/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal