Re: question about Trig spec

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.

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 08:30:58 UTC