Re: Reflection on the special telco of CSVW

On 10/09/14 12:42, Dan Brickley wrote:
> 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.

Yes.  The enviroment affects the "hook".

Ivan said:
"""
and add the hooks for further processing just like in Alternative2
"""

To a user, the whole process of CSV to their desired output is the task. 
  Not just some partial step.

We discuss {{foo.lowercase}} to mean make a call to lowercase the field. 
  That .lowercase is, in some proposals, as I understand them, a call to 
prog language-X.

>
> 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 12:10:05 UTC