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
