Re: question about Trig spec

On 16/09/13 13:39, Sandro Hawke wrote:
> 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.

What derivation of rules allows

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

?

A non [] blankNodePropertyList matches only:

[4g]	triples2	::=
	(blankNodePropertyList | collection) predicateObjectList? '.'


which must end in a '.'

so

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

is OK (bare Turtle, then a {} default graph part - ugly but hard to 
avoid) but

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

is not.

Could provide a concrete example and the parse rules you are reading?

	Andy

>
>        -- 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 20:14:46 UTC