[ubl-fpsc] Fwd: RE: UBL 0p70 comment "c.1" regarding rendering of UBL instances

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

When we discussed this question during our teleconference there were a 
number of ideas bandied about.  I invited additional comments and 
suggestions to the mail list, and seeing none I'm wondering if we are too 
far off on a tangent.

I took a step back on Friday and thought about the problem Mr. Burdett is 
trying to solve, and the role we are trying to play in providing committee 
interpretations of presentations of UBL instances.

I think I've come to the conclusion that the problem Mr. Burdett is trying 
to solve is different than the problem we are trying to solve, and that 
perhaps we (he and us) are looking at a far too complicated approach to a 
very simple problem.

Looking at the comments offered by Mr. Burdett:

>From: "Burdett, David" <david.burdett@commerceone.com>
>To: "'G. Ken Holman'" <gkholman@CraneSoftwrights.com>,
>    "Burdett, David"
>         <david.burdett@commerceone.com>
>Cc: UBL FPSC <ubl-fpsc@lists.oasis-open.org>,
>    "Probert, Sue"
>         <Sue.Probert@commerceone.com>
>Subject: RE: UBL 0p70 comment "c.1" regarding rendering of UBL instances
>Date: Fri, 11 Apr 2003 10:23:41 -0700
>...
>I'm not suggesting that there should be only one standard *way* to render 
>a UBL document. I am really suggesting a *mechanism* that allows a creater 
>of a UBL document to make it easy for someone who receives the document to 
>view it in human readable form in the way they intended.

This objective now screams out to me that "stylesheets do not answer the 
above problem".  When final form is so very important to the transmitter, 
the sender should utilize a final form format to *ensure* the recipient 
views a document in the way the sender intended.  Any other solution of 
trying to recommend or associate stylesheet technologies with an XML 
instance will give a false sense of accomplishment to the sender and is 
fraught with possible difficulties since the recipient could have any 
number of problems rendering the document as the sender intended:  they 
don't have a stylesheet processor, they don't have enough system resources 
to run a stylesheet processor, they don't have the required fonts 
installed, etc.

>Many businesses care about the way their business documents look and go to 
>a lot of trouble employing graphic artists and designers to make sure that 
>their paper documents present the image they want. What this means for 
>UBL, is that the creater of an XML Document might want to be able to 
>suggest to a recipient that a particular stylesheet be used to view the 
>document that makes the document viewable in the way the creater intended.

With such an investment in appearance, trusting the rendering to an arm's 
length process could

>So, if the sender of a document wants to associate a stylesheet with a 
>business document, then they need a way of doing it. This is why I 
>suggested adding in an optional stylesheet reference into each UBL 
>document so that that the creater of the document can *suggest* the 
>stylesheet to use to render the document into viewable form.

This does not ensure the stated objective to "make it easy for someone who 
receives the document to view it in human readable form in the way they 
intended".

>Note that the reference is just a * suggestion*. The recipient of the UBL 
>document does not HAVE to use the specified stylesheet and can use some 
>other stylesheet if they prefer.

A suggestion has far less weight than "in the way they intended", and the 
complexity of a solution to address something less important may not 
justify the effort involved to develop and support it.

>One of the main uses of this idea is by a simple utility that would:
>1. Accept a UBL document as input.
>2. Retrieve the stylesheet reference from the document
>3. Resolve the stylesheet reference into the actual stylesheet (see more 
>on this below)
>4. Pass the UBL document through the stylsheet to create something 
>viewable (e.g as HTML or PDF)
>5. Present the result to the user, e.g. using a browser.

This is a specific case of the general problem of associating resources 
with an XML instance.  The general problem involves: identifying possible 
resources to use with an instance, locating the given resources to use with 
the instance, being functionally able to process the instance with the 
given resources, being functionally able to work with the end result of the 
process.

>Some of the uses of this utility could be:
>1. By a SME who has no ERP or accounting system, who can view any UBL 
>document they receive, perhaps by email.
>2. To browse archives of UBL documents on an ERP system

I believe the objective of stylesheets is to render a document the way the 
*recipient* intends, not the way the *sender* intends.  To see information 
the way the sender intends requires using a final-form technology ... the 
most ubiquitous being PDF files.  The technology behind PDF files ensures 
the objectives to be met for the sender are satisfied.

This does not mean there isn't a role for stylesheets for the 
*sender*!  The sender can use our formatting specifications, find sample 
stylesheets meeting those specifications, modify the stylesheets for his 
specific rendering requirements, process those stylesheets in his 
environment with sufficient resources to produce the desired result, 
validate the desired result in the final form of what is intended from the 
raw information, and then package the final form with security protection, 
possibly encryption, turning on switches that prevent modification of the 
document, etc. all designed and implemented in the final form to protect 
"that which the sender intended the reader to see".

>Resolving the stylesheet reference is, though, an issue. There a number of 
>ways resolution could be done, for example:
>1. By including the stylesheet together with the UBL document in a 
>multi-part SOAP message using MIME or DIME
>2. By treating the stylesheet reference as a URL so that the stylesheet is 
>retrieved over the web - if you do this then caching the stylesheets 
>retreived could be a good idea.
>
>I think that this might be beyond the scope of this TC.

I quite agree.

>If you include a digital signature in the document (this was another 
>suggestion of mine) then you can bind the UBL instance and the stylesheet 
>so that you have a verifiable way of checking the authenticity of the way 
>the creater of the UBL document intended it to be viewed.

True ... but that again is adding a lot of complexity that is already being 
solved elsewhere in final-form-based technologies.

>Finally, I think that including a stylesheet reference in a UBL document 
>HAS to be optional, i.e. a UBL document is valid without one. In this 
>case, I think that having a stylesheet that allows any UBL document of a 
>specific type (i.e. order, invoice, etc) to be viewed is also a good idea.

And, in my opinion, this is the objective of the *recipient* using 
stylesheet technologies with XML instances ... to give them the control to 
look at XML they way they want.

If the sender wants control then the sender could choose to use stylesheet 
technologies internally but must use final-form technologies externally.

Before I start to draft a formal response along the lines of the above, 
citing Stylesheet Association and SOAP attachments as Dan did regarding 
established practices for applying stylesheets to XML documents in general, 
please let me know your opinions on my musings above.

To recap the original question as posed to the LCSC group, it was quite 
simple:  "There is no standard way of rendering a UBL document into human 
readable form".  I think we will have to go into the details cited by Mr. 
Burdett in his letter to us to ensure we have covered the bases of what was 
behind the original comment.

My proposed response is along the lines of "Final-form technologies such as 
PDF already exist for ensuring final-form fidelity and the rendering of 
intent.  Stylesheet technologies are inappropriate to satisfy these 
requirements.  Protocols for suggesting stylesheet use with an XML instance 
already exist, without attempting to fulfill the assurances provided by 
final-form technologies.  Duplicating the assurances by adding features and 
fields to UBL instances would be inappropriate.  Stylesheet technologies 
are still appropriate to be used by the sender in the accomplishment of the 
final-form objective needed for the recipient.  We recommend no specific 
additions to the UBL document models in regard to stylesheet technologies."

Do you think this is a sufficient response of our committee to the issue 
that needs to be addressed by LCSC?

Thanks!

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

--
Upcoming hands-on courses:   Europe (XSLT/XPath):    May  5, 2003
-                            Europe (XSL-FO):        May 16, 2003
- (XSLT/XPath and/or XSL-FO) North America:      June 16-20, 2003

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)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 0-13-140374-5                              Definitive XSL-FO
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-10-1              Practical Formatting Using XSL-FO
Male Breast Cancer Awareness http://www.CraneSoftwrights.com/o/bc