Re: Template as mechanism for CSV conversion.

On 14/05/14 19:15, Jeni Tennison wrote:
> Thanks Andy,

Hi Jeni,

Wouldn't it better to define a basic conversion and assume later 
processing, rather than putting all the features, inc calls outs, inside 
the processing model?  Conversion does not have to be a single step - it 
isn't anyway as CSV parsing is out of scope.

> I think it makes a lot of sense to have a general purpose template
> for mapping CSV to other formats (eg YAML, HTML). Open Refine does
> something similar as described here [1], which enables you to
> define:
>
> * a prefix
> * a template for each row
 > * a row separator
 > * a suffix
>
> What about using an existing templating system such as Mustache [2]
> which has the advantage of being implemented across lots of
> programming languages? Then you only have to define how the variables
> that get passed into the template get set up, not the syntax. (I’m
> not fixated on Mustache — I’d much prefer something more standard —
> it’s just that I’d really prefer not to have this Working Group
> invent a new syntax for templates.)

Mustache is aimed at HTML:
"""
All variables are HTML escaped by default. If you want to return
unescaped HTML, use the triple mustache: {{{name}}}.
"""
> I have three areas of concerns which mostly relate to the limited
> flexibility that something like Mustache gives you:
>
> 1. In all the real-life conversions I’ve ever done I’ve always ended
> up needing conditional statements of some sort. Which means having
> some kind of logical statements, which means adopting a particular
> programming language to express them in.

Examples?

(Mustache has conditional sections - a limited form of conditionality)

>
> 2. In all the real-life conversions I’ve ever done I’ve always ended
> up needing to process individual values in some way (ie some level of
> string parsing), which means defining functions.

Examples?

> 3. In all the real-life conversions I’ve ever done that have involved
> text-based templating languages that need to produce something with a
> defined structured syntax I’ve always gotten it wrong and produced
> non-well-formed/valid output.

!!

>
> All of which means that while I’m sure that templating is a useful
> thing to provide for general-purpose conversions, I still think
> there’s a need for more general purpose languages to “bug out” to.
> And I’m not 100% convinced (but we’ll only see by doing) that it will
> be possible to define useful conversions to other formats using
> templates. For example, just naming things like elements/attributes
> in XML and things like properties in JSON will require different
> approaches, I think, that it will be hard to express in generic
> templates.

I don't understand that last point : could you explain please? (by 
example?)

>
> Cheers,
>
> Jeni
>
> [1] https://github.com/OpenRefine/OpenRefine/wiki/Exporters

> [2] http://mustache.github.io/
>
> ------------------------------------------------------ From: Andy
> Seaborne andy@apache.org Reply: Andy Seaborne andy@apache.org Date:
> 14 May 2014 at 18:16:10 To: CSV on the Web Working Group
> public-csv-wg@w3.org Subject:  Template as mechanism for CSV
> conversion.
>
>> (from the telecon - JeniT asked for this to be made more visible on
>> the list)
>>
>> Gregg has suggested that if all the conversions are based around
>> the template mechanism, then there could be one conversions
>> document for all of RDF, JSON and XML.
>>
>> That makes sense to me although I also think that someone arrives
>> at the doc wanting, say, the details of JSON conversion, having
>> them all in one place makes for a less focused document.
>>
>> e.g. RDF: http://w3c.github.io/csvw/csv2rdf/#graph-template
>>
>> The templating mechanism is text-based and does not require parsing
>> of some variant of the output syntax ("variant" because of the need
>> for template slots). A processor may provide additional validation
>> of the output but, at a minimum, it can generate output just by
>> text processing (and potentially get illegal syntax due to the
>> lightweight nature of the process).
>>
>> A starting point for templates is URI Templates
>>
>> http://tools.ietf.org/html/rfc6570
>>
>> although there needs to be escaping per syntax support.
>>
>> (*nix) Shell parameter expansion is a similar mechanism.
>>
>> http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameter-Expansion
>>
>>
(not the array bits)
>>
>> ${parameter/pattern/string} is a regex replace, for example.
>>
>> Andy
>>
>>
>>
>
> -- Jeni Tennison http://www.jenitennison.com/
>

Received on Wednesday, 14 May 2014 21:38:31 UTC