Re: question about Trig spec

On 09/16/2013 04:30 AM, Andy Seaborne wrote:
> On 16/09/13 04:36, Sandro Hawke wrote:
>> None of these are show stoppers, but I'd like to understand....
>>
>> - Why are we using application/trig instead of text/trig (since Turtle
>> is text/turtle)   (I guess maybe we decided the IETF process was too
>> difficult with the text tree?  Or it's too annoying to include the
>> charset="utf-8" ever time?)
>
> (That was in the doc when I started as editor  - I'll try an answer 
> what I can:)
>
> Guessing history:
>
> 1/ Traditional trig used application/x-trig and this is close.
>    (just google - I found various uses of application/trig)
>
> 2/ Yes - the UTF-8 issue is significant
>    (I've already seen problems with this on text/turtle)
>
> 3/ text/turtle was not a decision of any WG - W3C registered it 
> beforehand.
>
>>
>> - What is the justification for grammar note 9?   I see Turtle has the
>> same problem.   Why can't we just say "@prefix" and "@base" are language
>> tags when they occur as such in the grammar?    Of course it would have
>> to be special cased with traditional parser generators, but it doesn't
>> seem like it'd be hard.  (I guess we went back on forth on this and gave
>> up in disgust?)
> (ditto)
> EricP may have more to say about this.
>
> If you have a tokenizer that generates typed-tokens from @... then the 
> grammar is confused by whether it's a language tag or a directive 
> (effectively, it's context sensitive).  With a pure grammar-tokenizer 
> split, this needs special handling.   The note (just copied over from 
> Turtle) is to highlight that.
>
> ((Hindsight:
> Maybe it would have been ideal to have the whole of literal as a 
> token, not a grammar rule, so including ^^ and @ parts in tokenization 
> but it is way too late to do that because it is this way in original 
> Turtle)
> ))
>
>>
>> - is it a bug that the grammar says (blankNodePropertyList | collection)
>> can preceed { } but not if GRAPH is used?  How about getting rid of
>> triples2 and instead change labelOrSubject to include alternatives
>> blankNodePropertyList and collection?    I don't have a working
>> grammar-driven-parser right now, so maybe I'm doing that wrong in my 
>> head.
>
> It was intentional as being the conservative choice.
>
> We did discuss
>
> GRAPH [:p 123 ; :q "" ] { ... }
> [:p 123 ; :q "" ] { ... }
>
> but c.f.
>
> [:p 123 ; :q "" ] :predicate :object .
>
> the discussion did not result in an agreement.  Restricting the graph 
> name to a single term form, not a triple generating one, is the 
> conservative choice at this point in time.
>

I don't have any opinion about whether we should allow

GRAPH [:p 123 ; :q "" ] { ... }
and
[:p 123 ; :q "" ] { ... }

but as I read the grammar it seems to be saying we allow the second of 
those two, but not the first.  And that doesn't seem good.

I agree the conservative route is to forbid this construction, but if 
so, I'd think we should forbid it in both forms.

       -- Sandro

> It would apply if the word GRAPH were not used via triplesOrGraph
> (caveat: I do not have my reference parser on this machine)
>
>     Andy
>
>>
>> Thanks.
>>
>>         -- Sandro
>>
>>
>>
>>
>>
>>
>
>
>

Received on Monday, 16 September 2013 12:39:50 UTC