RE: [ubl-dev] Simple description of XML-Spreadsheet format

["David RR Webber \(XML\)" <david@drrw.info>]

Chin,

You may be making this way too complex.

<thisWorks>
<row this="123" that="ABC" other="2008/04/03"/>
<row this="124" that="ABCD" other="2008/04/07"/>
<row this="129" that="ABCE" other="2008/04/08"/>
<row this="132" that="ABCF" other="2008/04/09"/>
</thisWorks> 

save this to XML - open in Excel. Will make perfect spreadsheet.

I've used this very successfully outputting from XSLT and in combination
with CAM templates. 

Thanks, DW 

-------- Original Message --------
Subject: Re: [ubl-dev] Simple description of XML-Spreadsheet format
From: Chin Chee-Kai <cheekai@softml.net>
Date: Thu, September 18, 2008 12:37 pm
To: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
Cc: UBL-Dev <ubl-dev@lists.oasis-open.org>

G. Ken Holman wrote:
> Chee-Kai, you may consider publishing these UBL v1.0 IDD spreadsheets 
> as genericode files so that you are using a standard representation:
>
> http://docs.oasis-open.org/codelist/genericode/
>
> UBL v2.0 IDD spreadsheets are available in XML format using genericode 
> ... the latest version I published was in July 2007:
>
> 
> http://www.CraneSoftwrights.com/resources/ubl/index.htm#ubl2idd2genericode 
>
Thanks for highlighting this, Ken. Much delighted to see genericoding 
of the spreadsheet values for UBL v2.0. It's certainly good to be using 
the genericode standard for coded values. I took a look at your 
pointer above and compared carefully between the genericode format and 
XML-Spreadsheet (by no means an official name, I'm just using it to 
describe "that" format which I'm using) format to see if I could merge 
and use the standard.

I haven't really ploughed through the whole history of genericode, but 
from the nice intro on your web page and browsing the examples .gc 
files, I get the sense that genericode is, as its name suggests, 
designed more to represent code lists, though there can be creative use 
in other purposes like representing model spreadsheets.

I think that although the two formats look similar with the <Row> 
elements, their intents, purposes, structures, and content values are 
quite drastically different from what I can see. As I briefly described 
in the earlier intro posting, the XML-Spreadsheet is intentionally 
simple, and purposefully crafted so that it reflects as faithfully as 
possible the various pieces of datum found in the original spreadsheet.

If this objective is closely followed, then some special uses become 
possible, such as allowing a user's customized spreadsheet, whose 
columns and rows might have been changed much, to be converted 
faithfully into an XML format. Also, when UBLish v2.0 becomes 
available, users can generate their own native/proprietary or customized

spreadsheets directly. So XML-Spreadsheet's format needs to be flexible 
enough to allow various kinds of spreadsheets so that users can relate 
the XML format conveniently to the spreadsheet coordinates.

The advantage of genericode to store model spreadsheets (CommonLibrary 
and main documents), the way I see it, is that it contains processed 
linkages of related and essential values, so that perhaps lesser 
processing needs to take place during use. In terms of "faithfulness" 
to original spreadsheet, for instance, I'm not exactly sure how to 
reduce spreadsheet's "Dictionary Entry Name" into "den", "Cardinality" 
into "card", why is "type" a <SimpleValue> whereas a "terms" is a 
<ComplexValue> and so on. That hidden conversion table and knowledge 
imply a knowledgeable converter (a utility software or human) that 
stores such a "mapping". It wouldn't quite serve a more general case 
where an arbitrary spreadsheet, such as one modified by user, is to be 
converted. Hence the introduction of XML-Spreadsheet format which links 
information such as row & column numbers back to spreadsheet. The 
purposes of both formats are quite different, so I understand the 
purpose of one cannot be used to justify the merit of the other.

(BTW, I think attribute names should, heeding good practice from UBL 
NDR, be lowerCamelCased. So attributes such as "ColumnRef", "Id", and 
"Use" should be lowerCamelCased. Just a thought)

> When the updated IDD is ratified I'll be republishing this resource 
> with the latest definitions.
>
> That way your IDD files and my IDD files will cover both versions and 
> will be in the same standardized vocabulary.
For the next release involving UBL v1.0 IDD draft spreadsheet, I'm 
getting ready the XML-Spreadsheet version and hadn't thought about using

genericode prior to your posting. After realizing the lack of "mapping" 
knowledge (mentioned above), I find it easier if you might want to try 
taking the v1.0 IDD XML-Spreadsheet to generate, in turn, genericode 
encodings of UBL v1.0 IDD since you've the tacit knowledge required to 
"get it right".

I would offer to work out the UBL v2.0 IDD draft if you could share the 
draft spreadsheet online somewhere. (Or perhaps by then UBLish v2.0 
alpha is released so you could just do the conversion yourself too)


Regards,
Chin Chee-Kai


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org