Is or will be available a stilesheet for XHTML? This way it is possible to read an invoice with a web browser.

Thank you for your question.

Based on the lack of interest in UBL 1.0 to XHTML after the effort had gone into making such a stylesheet, we decided at Crane not to put the time (yet) into a UN Layout Key version of UBL 2.0 to XHTML to stylesheet. The feedback from UBL 1 was that for the UN Layout Key, only a print version was acceptable and that a browsable version was unacceptable since the choice of layout geometry was geared to using paper.

However, there is a codex UBL 2.0 to HTML stylesheet available on Crane's web site. It is found in the same directory where these print stylesheets are found. This is used to render any UBL 2.0 instance (not just Invoice) to the web in a diagnostic style so that the information is exposed without having to see the angle brackets of XML.

But the rendering is not intended to be used as a "presentation" of an Invoice ... just a diagnostic exposition of the XML contents. There are no boxes or box labels, just a dump of all contents (even contents that do not have a home on the UN Layout Key) so that a human can inspect all of the content of a UBL instance without having to see the angle brackets.

Do you believe that a UBL 2.0 to HTML rendering of box lines, box labels and content approximating the UN Layout Key would be useful?

Here is an example from UBL 0.70 in PDF:

http://www.oasis-open.org/committees/ubl/lcsc/0p70/fs/samples/UN380Invoi...

... and in HTML:

http://www.oasis-open.org/committees/ubl/lcsc/0p70/fs/samples/UN380Invoi...

I admit the example above looks acceptable, but that is because it doesn't have a lot of data. There were complaints about the quality of the stylesheets when the data distorted the box alignments ... yet such complaints could not be resolved because it is up to the browser to worry about alignment of differing-sized boxes.

So the complaints led to a decision, at that time, to abandon the HTML rendering of the UN Layout Key. We could not overcome browser decisions that made our work look bad.

But I'm anxious to determine what your requirement is to assess if we should put the effort into trying to build another HTML rendering of the UN Layout Key.

Is your intention to merely read and understand the content of a UBL instance when in a browser, thus the codex stylesheet will suit your needs?

Or is your intention to see the UN Layout Key presentation of the UBL instance in a browser?

Note there are even more problems printing an HTML rendering of a form, again because of browser decisions that are outside of the control of the stylesheet writer.

If it was your intention to visually inspect an HTML rendering of the UBL instance and then print from your web browser, the end result is just not satisfactory.

If it is your intention to get a properly drawn printed page, then using the UBL to PDF environment will do that for you free of charge.

It was our thought that the HTML codex presentation was what people would use for ensuring the content was complete, and then the PDF UN Layout Key presentation was what people would use for ensuring the content looked nice.

Thank you for sharing your thoughts on this. It is important for us (commercially) to know what demand there is for viewing UBL. Please let us know what you believe is needed.

Note that from a committee perspective, the committee is responsible for guiding the commercial creation of presentations, not for creating the stylesheets themselves. The committee decided it would be up to industry to implement the guidelines created by the committee.

. . . . . . . . . . Ken

Just a quick note to report that the free environment to print a UBL 2.0 Invoice to PDF now supports box labels in 12 languages: Bosnian, Czech, Danish, English, Finnish, French, German, Italian, Norwegian, Portuguese, Slovak and Spanish.

Additions are welcome! Instructions are included in the readme file regarding how you can contribute a set of box labels.

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

The library has been updated with HTML stylesheets for the UBL Invoice in all 13 languages.

One group of academics argues for
the maximal definition which means speakers are as proficient in one language as
they are in others and have as much knowledge of and control over one language
as they have of the others. Another group of academics argues for the minimal
definition, based on use. Tourists, who successfully communicate phrases and
ideas while not fluent in a language, may be seen as bilingual according to this
group.

However, problems may arise with these definitions as they do not specify how
much knowledge of a language is required to be classified as bilingual. As a
result, since most speakers do not achieve the maximal ideal, language learners
may come to be seen as deficient and by extension, language teaching may come to
be seen as a failure.It's a great problem for website hosting companies to provide multi-lingual support web servers.One does not expect children to "speak chemistry" or to have become a professional athlete by the time they have left school, yet for graduating school children anything less than fluency in a second language could
be seen as inadequate.

Being uniligual myself, I rely on the kindness of volunteers to contribute the box labels used in the UBL invoice presentation.

I am unable to verify one way or the other if there are or are not problems arising from the definitions used.

Unfortunately, the hyperlink in your post gives the impression the post is spam and not really relevant to the thread.  Please clarify the nature of your comment related to the thread, and I'll be pleased to respond.

. . . . . . Ken

ahmet kara: please clarify the relevance of your comment to this thread.

Webmaster:  is there any way to tell if these off-topic posts are merely "bots" that find my thread particularly attractive to attach spam to?

Thanks!

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

A secure ID is the starting point for most in-house IT systems, but we really need a federated ID that is still secure for most of what we are now contemplating in terms of the people based Web 2.0 style interactions that are driving a lot of the new business value today. No where can this be more essential than  for eGovernment, or perhaps more importantly to allow e citizens to gain and use IDs. Of course there is nothing new about this, but it’s a lot easier to describe the requirement than to deliver the solution if for no other reason than we are not starting with a clean sheet of paper, i.e. everyone has some level of an ID solution already, and, federation means getting lots of different people and enterprises to agree on a common interest being as important, if not more important than their own interests.

 The wish list has been in place for some time now, as well as some of the basic ingredients to build on, so we are now in the boring, but critical phase of actually getting some real basic hard ‘nuts and bolts’ work done. I assume it’s for this reason that the announcements of some very real success didn’t hit the headlines, too far after the ‘sexy announcement’ and too much around the boring engineering detail. So what and where have we got to now?