Re: Reflection on the special telco of CSVW

On 10 September 2014 12:27, Ivan Herman <ivan@w3.org> wrote:
>
> On 10 Sep 2014, at 12:21 , Andy Seaborne <andy@apache.org> wrote:
>
>> One aspect of this choice is whether a transformation of a CSV file to be published on the web so other people (other than the data publisher) run it?  Or is it the input for a toolkit to generate format X and then a file with format X is put on the web?
>>
>> If transforms are published, then there is a requirement for a programming-language, template-language independent solution.  I agree this is more work.
>
> But the point is that such programming languages already exist. Several of them. One could say that we should not define yet another one.

I have the feeling that we're talking past each other some of the time
here. Reading Andy here, my first reading was that requiring a
"template-language independent" template/transform language seemed
like a contradiction. But I guess the idea is that we want portability
between specific template/transform software packages / projects. So
for example, emphatically blessing something as specific as Django
just wouldn't make sense for W3C, even though we might want to make it
possible in metadata for the Django-loving subset of the Web community
to declare associated templates via JSON-LD metadata.

The {{ mustache }} -based notations seem to be common enough that they
transcend any particular software project and programming language.
But there are some {{ }}-based template systems that slip rather
casually into assuming full Javascript capabilities, which is
something we ought to be very wary of doing. There is an interesting
design space between simple variable interpolation vs turing complete.

e.g.  http://www.polymer-project.org/docs/polymer/expressions.html
("Polymer supports expressions in {{}} with a strict subset of the
JavaScript language. In order to use this feature, it’s important to
understand its behavior and limitations: The goal for inline
expressions is to allow the expression of simple value concepts and
relationships. It is generally bad practice to put complex logic into
your HTML (view).").


> If a template format is defined (complex or simple), then one can also publish the templates (e.g. [1,2]).
>
> In other words, I am not sure I understand your point in terms of deciding whether we do templating or not.
>
> [1] https://github.com/w3c/csvw/blob/gh-pages/experiments/simple-templates-jquery/simple_test/test-json.tmpl
> [2] https://github.com/w3c/csvw/blob/gh-pages/experiments/simple-templates-jquery/simple_test/test-turtle.tmpl
>
>
>>
>> Assuming javascript is a possibility; while it is arguably the safest single choice, it does not work for many environments.  If you're in a lang-X programmer (e.g. R), you want to use lang-X skills.
>>
>> Otherwise, if it's a tool-input and not published to be run elsewhere, it does not need this portability requirement.  A language or a basic-transform+improve style is more reasonable.  The tool space is weaker (transforms are tool specific).
>>
>
>
> I do not understand. *If* we define a template language (simple or complex), it can be defined in different languages. I happened to have that done in Javascript, but it could have been done in Python without too much problems.

Ivan - when you say "it can be defined in different languages", can I
read "can be implemented" in different languages? Your implementation
seemed to be of a mustache-family language that *happened* to be
implemented in Javascript. I would hope that the same templates could
equally well be processed by Java, Python etc. implementations, and
that a group like ours should be capable of writing unit tests to
probe the behaviour of such implementations.

Dan

Received on Wednesday, 10 September 2014 11:42:46 UTC