requirements (was: Re: Adding implicit string values)

> On 15,Apr2021, at 7:13 AM, Steven Pemberton <steven.pemberton@cwi.nl> wrote:
> 
> On Thursday 15 April 2021 12:02:12 (+02:00), Tom Hillman wrote:
>> ...
>> 
>> Implicit values like this might be more of a stretch, but it seems desirable to me that a non-XML markup document like:
>> *this*
>> 
>> should be interpreted with corresponding grammars to either of the following representations using iXML:
>> <html:span class="emphasis">this</html:span>
>> <i>this</i>
> 
> But now you are targeting specific XML document types, which was not in the requirements of ixml. 
> 


At the risk of starting a hare that might be difficult to catch, I wonder if we should at some point attempt an explicit statement of the requirements ixml is trying to meet?

As a group we are in a slightly delicate position because up until now the idea of ixml has been Steven’s baby, and any shift from being the responsibility of a single individual to being the responsibility of a group is potentially fraught.  And discussions of requirements can feel like shadow boxing when they are conducted in the abstract and not in light of the concrete implications people attach to this or that requirement.

The current spec mentions general requirements in one sentence (at least, as far as a search for “req” reveals):

> We choose which representations of our data to use, CSV, JSON, XML, or whatever, depending on habit, convenience, and the context we want to use that data in. On the other hand, having an interoperable generic toolchain such as that provided by XML to process data is of immense value. How do we resolve the conflicting requirements of convenience, habit, and context, and still enable a generic toolchain?

The phrase “generic toolchain” seems to me to suggest that the required task of an ixml parser is to get the input into some XML, not to get it into a specific form of XML.  Tom and I have suggested a few things aimed at giving the grammar writer more control over the form of XML produced, and if a strict and minimalist view of the requirements is taken, everything we have suggested is either out of scope entirely or at best a desideratum.  

I think the rule for desiderata should in this case be:  if we can achieve the goal by adding a bit of mechanism, what is the ratio of added advantage (extra expressive power and convenience) to cost (complexity of the mechanism)?  And how does that ratio compare to the corresponding ratio for what is already in the spec?

As a comparison point, anyone interested in topics like two-way translation, injection of data into the XML (or into the non-XML), and re-ordering may find it interesting to read up on Xsugar.  They do allow at least some kinds of two-way translation, and injection of constant (context-determined) data, and re-ordering.  And I think they do a fairly nice job.  But subjectively, their power : mechanism seems a notch below that of ixml.  (Subjective assessments of metaphoric ratios are of course difficult to justify, so I won’t try.  I only know that that is my judgement because I notice that I am interested in their papers and interested in learning what I can from them to make ixml more powerful, but I have not experienced any perceptible desire to use Xsugar instead of ixml.  The spareness of ixml is, I think, a bit part of what makes it attractive to me.)

Michael

********************************************
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
cmsmcq@blackmesatech.com
http://www.blackmesatech.com
********************************************

Received on Thursday, 15 April 2021 15:32:15 UTC