[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Human Interface Group -UBL
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]