Re: Turtle LC Draft

On Fri, Jun 22, 2012 at 4:02 AM, Ivan Herman <ivan@w3.org> wrote:
> Gavin,
>
> minor issues
>
> - the references to RDF Concepts are all to the Mercurial repo version. It should point at the TR document (probably to the short-named URI)

They will in fact work when in the TR space as they are relative to
the current location of the Turtle document ;) I can just make them
point at the TR now that RDF Concepts has been published.

> - the LC comment period is said to end on the 15 August. With all the summer vacations coming up, I would think that 1st of September, or even 15th of September, would be a better idea. (this requires a WG decision)

Yeah, I just made it up since respec required a date.

> - refrenced -> referenced (Section 2.2, first sentence)
> - equalivate -> equivalent (Section 2.4, 2nd bullet item following the 5th paragraph)
> - diffrent -> different (Section 2.4, paragraph following a note)

Whoops... will fix.

> - in section 2.5.1, there is a reference "absolute IRI, a relative IRI or prefixed name." that does not seem to lead anywhere within the document

Huh, will fix.

> - in section 2.5.2., the text says "Turtle has syntax for writing integer values, arbitrary precision decimal values, double precision floating point values and boolean values.". The section is entitled "Numbers", but boolean is not a a number (and has its own subsection). I would propose to remove 'and boolean values'

Ah, yes. Left over from other section break ups.

> - Appendix A says: "The character encoding of the embedded Turtle will match the HTML documents encoding.". Isn't this in contradiction to the fact that Turtle must be UTF-8? Formally, that means a turtle parser cannot just take the content of the <script> element and parse it, it has to make it sure that it is converted into UTF-8 first. Propose: add a remark to A.2 that the content of the <script> element must be converted to UTF-8 before being parsed by a Turtle parser.

Not exactly true. If parsing from HTML the parser may need to simply
accept a character stream rather than a byte stream. Providing
specific instructions on what to do with the encoding feels a bit too
restrictive on how it could be parsed. For example a JavaScript parser
would likely see the character stream from the DOM and not even care
about the encoding. If you used libhtml5 or another DOM parser to
parse the HTML the same would also be true.

> - Appendix B, Media type: I am surprised to see 'Ian Davis' as a contact person for the media type. Any specific reason for that? Note that Eric's name already appears down the line as contact person, so I am not even sure why there are two (and different) entries. Propose to remove Ian's name.

/shrug haven't changed anything here. Eric, how should this be updated?

> - Appendix B says: "No widely deployed applications are known to use this media type. It may be used by some web services and clients consuming their data.". That sounds funny. First of all, I would consider LOD endpoints (eg, DBPedia) as widely deployed, although measures differ. But I do not really see the value of the second sentence...

Again, haven't changed anything. I assume that was in the original submission.

>
> Cheers
>
> Ivan
>
> On Jun 22, 2012, at 24:58 , Gavin Carothers wrote:
>
>> Hi folks,
>>
>> The Turtle LC Draft is available at
>> http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-turtle/index.html#
>> Please review before the next telecon so we can get a resolution to
>> publish!
>>
>> Cheers,
>> Gavin
>>
>> PS.
>>
>> The Acknowledgements section will need to be updated before
>> publication ;) Thanks to everyone who has reviewed and provided
>> feedback so far!
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>

Received on Friday, 22 June 2012 13:21:30 UTC