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

[Chin Chee-Kai <cheekai@softml.net>]

G. Ken Holman wrote:
>> They are readily produced using UBLish v2.0.alpha using the 
>> XML-Spreadsheet function and selecting the batch directory conversion.
>> Perhaps this XML equivalent version might be useful as an input into 
>> further transformation into genericode representations because it is 
>> already in a simple XML format.
> Thanks, Chee-Kai, but no thanks.  As mentioned before, I'm already 
> using other preexisting standardized vocabularies rather than 
> inventing my own.
That's no problem, Ken.

However, while you're certainly entitled to choosing your desired format 
to store the IDD spreadsheet cell values, I do need to point out that 
the objective of XML-Spreadsheet with simple <Row> and <Column> elements 
is not for "inventing my own", but to reflect the structure with respect 
to spreadsheet's matrix (2D) structure.  It is not appropriate to 
compare the apparent formats (genericode and XML-Spreadsheet) and say 
one is standard and other is yet-another-invention; it depends on usage 
and most importantly, cost of implementation, understanding, creating, 
maintaining, reusing and so on.

For example, I can easily recover the precise positioning and cell 
values  from XML-Spreadsheet so as to re-populate Excel (or ODF) because 
the coordinates are there.  Genericode has more of a list-oriented 
nature, and discards coordinate information.  Again, it's not whether it 
is better or worse than the other.  I just find the comparison, or the 
implied pros-and-cons comparison, doing an unnecessary disservice to the 
other format.


> I do not share your earlier observation that genericode is limited to 
> codes:
All programs can be written in  1's and 0's, but we don't see everyone 
writing kilometers of 1's and 0's to develop software.  My observation 
is based on genericode's list-oriented (or set-oriented, depending on 
whether one  uses the implied position information of physical locations 
of the elements) nature, and it is my deduction that genericode is 
better suited for codes.  You can hack a lot of other things into 
genericode and claim that it is suited for C++ and Java programming, but 
that's certainly another opinion.  I respect that you see genericode as 
being more useful in storing IDD values.


> At 2008-09-19 03:37 +0800, Chin Chee-Kai wrote:
>> 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.
>
> The conclusion above does not recognize that, in fact, genericode is a 
> standardized representation of a keyed table information set, where 
> codes are the keys, and can be used generically regardless of the 
> actual element names. 
You seem to have pointed out the primary objection of using genericode 
to store matrix-like spreadsheet values in the same sentence :)   
Matrix-structured spreadsheets have no keys.  The litmus test is if we 
start from genericode-represented values, can we re-populate the 
spreadsheet in exactly the same manner as the original.  
XML-Spreadsheet, yes.  Genericode, no.  End of proof.  Again, this proof 
shows nothing but that XML-Spreadsheet is useful in accessing cell 
values if user has a matrix model in mind.  But if user's application is 
such that key associations  is more readily programmable, then perhaps 
genericode version is more appropriate.

To produce genericode, you need to *decide* how to produce the keys from 
a keyless structure.  That is where yet more standardization takes 
place, such as how to collapse the column labels with suitable formulas, 
how to expand them again, and so on.

I also don't think UBL should formally endorse/encourage the use of 
another format (standard or otherwise) which doesn't follow UBL's own 
NDR, especially more so when we're talking about finding a non-primary 
supporting  format to hold the cell values of normative IDD.


> And now with the combination of the HTML summary and the XML 
> representation, perhaps developers don't even need the actual IDD 
> spreadsheet files anymore.
For some development needs, it may be useful to add or modify the IDD 
cell values so as to give the description better context within their 
applications.  As I pointed out in my earlier postings, an example might 
be tool tip help text which a developer might wish to show.  In this 
case, s/he might alter the cell value of, say Company ID, to  append 
text such as "Enter  the company registration number as registered with 
Authority".  If so, then there'll be a need to re-generate the 
XML-Spreadsheet (or for your case, genericodes) again.


> Anyway, as discussed before there is no right way or wrong way, and it 
> is good that the community has choice ... hopefully they'll be aware 
> there is a choice.
Agree.


regards,
Chin Chee-Kai