[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Simple description of XML-Spreadsheet format
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]