Re: Template as mechanism for CSV conversion.

On 14/05/14 18:25, Gregg Kellogg wrote:
> On May 14, 2014, at 10:14 AM, Andy Seaborne <andy@apache.org> wrote:
>
>> (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).
>
> We could handle this by publishing notes on CSV2RDF, CSV2JSON and
> CSV2XML which discuss the application of the spec to those specific
> formats, and reference the generic CSV template transformation.

Seems reasonable as an endpoint.

If we have a doc that is the formal definition of conversion (including 
the text which Jeni has put in the metadata doc), and ones in more 
informational style for each syntax.

And for convenience of creation, one document with major sections.

>> A starting point for templates is URI Templates
>>
>> http://tools.ietf.org/html/rfc6570
>>
>> although there needs to be escaping per syntax support.
>
> As it's not specifically intended for templating literal types, we
> may need to extend this for datatype-specific template requirements,
> and to define escape mechanisms that may need to be required.

Yes - this is a good case for starting with RFC 6570 as it has the 
concept of position dependent escaping rules.  Any URI generated
requires that as does the carrier syntax.

I think for for the first round, we restrict the process to substitution 
of values (possibly with conversion e.g. case, regex) and not have 
structural templating (the shape of the RDF changes based on column 
values).  It needs UC evidence to go further and also to show that 
processing as RDF->RDF (JSON->JSON, CSV-LD->CSD-LD) isn't enough.

	Andy

>> (*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.
>
> This can be quite powerful.
>
> Gregg
>
>> Andy
>>
>
>

Received on Thursday, 15 May 2014 09:18:03 UTC