Re: Template as mechanism for CSV conversion.

Thanks Andy,

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.)

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.

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.

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.

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 18:15:31 UTC