OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-fpsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Thank you for your comments, Chee-Kai!

At 2003-04-29 10:19 +0800, Chin Chee-Kai wrote:
>The way information is presented
>on business documents is itself a part of the information being
>presented.
>...
> >>I believe the objective of stylesheets is to render a document the way the
> >>*recipient* intends, not the way the *sender* intends.
>
>Not quite, in the case of business documents.  Sender would not
>want his/her own company logo to be minimized by the recipient
>below the page number at the bottom;  nor would sender wants,
>for example, reference numbers be printed right-to-left because
>recipient's system by default does that.  I don't think that
>recipient-controlled presentation makes sense for UBL documents.

Note that I said "for stylesheets".  For final-form documents, I totally 
agree with you: the sender must be in control and be responsible to make 
the final-form rendition.

>It could be a choice, but must not be the only choice.

All stylesheets in XML are, by their nature, by choice.

I feel this discussion has brought to light (in my opinion) that 
stylesheets provide two essential facilities:

(1) - a technology choice for senders of UBL documents in the creation of 
the sacrosanct, protected, final-form rendition of the information the way 
the sender intends without the ability for the recipient to change it

(2) - a rendering choice for recipients of UBL documents to examine the 
information in alternative presentations, though never with the authority 
of the sender's protected final-form rendition

And, I believe both will be "customers" of our committees work products: 
Senders will want to adopt our specifications to their specific needs in 
the creation of the sacrosanct "official" copy, and recipients will want 
alternatives to look at, present and analyze documents for their own purposes.

> >>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.
>
>Yes, that pretty much is it, to use a prevalent and easily usable
>final-form technology to do that.  PDF does more than just presenting
>actually;  it prevents the recipient from arbitrarily re-orienting
>the presentation component blocks within the document, whether
>intentionally or because the system somehow defaults to that
>behavior.

So very true ... therefore, I think we can remain *very* loose in the 
application of stylesheets because recipients do not have constraints and 
the sender might utilize stylesheets in the production of the final product 
but the final product will be so very tight that stylesheets shouldn't have 
a recipient role in the "official" rendition.

So much so, that we should reinforce this perspective by not adding any 
stylesheet-specific properties to a UBL document.

>Presentation as HTML could be another way, although
>less "air-tight" than PDF.

And I wouldn't think a company would want the "official" version to be in 
HTML, only a "review" version.

Oh, another thing that came to mind to me:  another reason the "official" 
version should *never* be the recipient's application of a stylesheet is 
that the recipient might not be in possession of the necessary stylesheet 
technology.  Even if it is freely available, they might not have the 
capacities on their machines to process the information.  PDF files would 
be ubiquitous and available to all.

Any other opinions?  Should we suggest to LCSC that we add nothing to UBL 
document models w.r.t. stylesheets?

.................... 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]