Re: Reflection on the special telco of CSVW

first, (admittedly being a bit offline over the past months on CSV on the Web and our main participant 
in the group only being back next week), I have the (cautious) tendency to opt rather for Alternative 
2, in case. wouldn't Alternative 1 essentuially mean re-inventing R2RML  (again, apologies if I missed
that part in the discussion and would be grateful for pointers)? 
This also goes into the direction of

>>> But the point is that such programming languages already exist. Several of them. One could say that we should not define yet another one.



second, as a side note, just thinking out loud here on the mustache {{ }} syntax... 
Assuming I have RDF as output for a canonical conversion and want to use SPARQL CONSTRUCT as a 
base language for a more complex transformation on top of that. Then, {{ }} would probably not 
go nicely with parsers(?), since {{ }} may occur to separate group graph patterns.

Thanks,
Axel


On 10 Sep 2014, at 15:00, Ivan Herman <ivan@w3.org> wrote:

> 
> On 10 Sep 2014, at 13:42 , Dan Brickley <danbri@google.com> 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.
>> 
>> 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).").
>> 
> 
> Right. I do not think any of the features that we discussed around templates (the discussion led by Jeremy or the stripped version I played with) are language specific. And indeed they should not. 
> 
> 
>> 
>>> 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?
> 
> I am sorry. Answering a mail while on a meeting is bad:-) 
> 
> s/defined in/implemented in/
> 
> 
>> 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.
> 
> Absolutely. The core of it is doable in Python (because there is also a Mustache implementation in Python, the necessary effort would not be bigger). I am sure that is the case for other languages, too. And to be very clear: I used an existing Mustache implementation because I am lazy, and did not want to spend time in implementing the {{.}} template management myself; I am not committed to Mustache (and I use a small part of it).
> 
> Ivan
> 
> 
>> 
>> Dan
> 
> 
> ----
> Ivan Herman, W3C 
> Digital Publishing Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> GPG: 0x343F1A3D
> WebID: http://www.ivan-herman.net/foaf#me
> 
> 
> 
> 
>

Received on Wednesday, 10 September 2014 12:16:57 UTC