RDF Web Applications Working Group Teleconference

Minutes of 18 August 2011

Agenda
http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0034.html
Seen
Gregg Kellogg, Henri Bergius, Manu Sporny, Niklas Lindström, Shane McCarron, Stéphane Corlosquet, Ted Thibodeau
Guests
Stéphane Corlosquet, Henri Bergius, Niklas Lindström
Chair
Manu Sporny
Scribe
Manu Sporny
IRC Log
Original and Editable Wiki Version
Resolutions
  1. Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements. link
  2. Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document. link
Topics
13:56:24 <RRSAgent> logging to http://www.w3.org/2011/08/18-rdfa-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2011/08/18-rdfa-irc

13:56:26 <trackbot> RRSAgent, make logs world

Trackbot IRC Bot: RRSAgent, make logs world

13:56:28 <trackbot> Zakim, this will be 7332

Trackbot IRC Bot: Zakim, this will be 7332

13:56:28 <Zakim> ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes

Zakim IRC Bot: ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 4 minutes

13:56:29 <trackbot> Meeting: RDF Web Applications Working Group Teleconference
13:56:29 <trackbot> Date: 18 August 2011
13:56:33 <manu> Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Aug/0034.html
13:56:38 <manu> Chair: Manu
13:56:38 <manu> Guest: Stéphane (scor) Corlosquet
13:56:38 <manu> Guest: Henri (bergie) Bergius
13:56:38 <manu> Guest: Niklas (lindstream) Lindström
13:57:23 <Zakim> SW_RDFa()10:00AM has now started

Zakim IRC Bot: SW_RDFa()10:00AM has now started

13:57:30 <Zakim> +??P2

Zakim IRC Bot: +??P2

13:57:48 <lindstream> zakim, I am ??P2

Niklas Lindström: zakim, I am ??P2

13:57:48 <Zakim> +lindstream; got it

Zakim IRC Bot: +lindstream; got it

13:58:44 <Zakim> +??P14

Zakim IRC Bot: +??P14

13:58:49 <manu> zakim, I am ??P14

Manu Sporny: zakim, I am ??P14

13:58:49 <Zakim> +manu; got it

Zakim IRC Bot: +manu; got it

13:59:04 <Zakim> +??P8

Zakim IRC Bot: +??P8

13:59:18 <gkellogg> zakim, I am ??P8

Gregg Kellogg: zakim, I am ??P8

13:59:18 <Zakim> +gkellogg; got it

Zakim IRC Bot: +gkellogg; got it

13:59:57 <Zakim> +OpenLink_Software

Zakim IRC Bot: +OpenLink_Software

14:00:02 <Zakim> + +358.405.25aaaa

Zakim IRC Bot: + +358.405.25aaaa

14:00:09 <MacTed> Zakim, OpenLink_Software is temporarily me

Ted Thibodeau: Zakim, OpenLink_Software is temporarily me

14:00:09 <manu> Zakim, aaaa is bergie

Manu Sporny: Zakim, aaaa is bergie

14:00:09 <Zakim> +MacTed; got it

Zakim IRC Bot: +MacTed; got it

14:00:12 <MacTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

14:00:12 <Zakim> MacTed should now be muted

Zakim IRC Bot: MacTed should now be muted

14:01:01 <Zakim> +??P29

Zakim IRC Bot: +??P29

14:01:05 <ShaneM> zakim, I am ??P29

Shane McCarron: zakim, I am ??P29

14:01:05 <Zakim> +ShaneM; got it

Zakim IRC Bot: +ShaneM; got it

14:02:03 <manu> zakim, who is on the call?

Manu Sporny: zakim, who is on the call?

14:02:05 <Zakim> On the phone I see lindstream, manu, gkellogg, MacTed (muted), +358.405.25aaaa, ShaneM

Zakim IRC Bot: On the phone I see lindstream, manu, gkellogg, MacTed (muted), +358.405.25aaaa, ShaneM

14:02:52 <Zakim> -ShaneM

Zakim IRC Bot: -ShaneM

14:03:49 <Zakim> +??P29

Zakim IRC Bot: +??P29

14:03:52 <ShaneM> zakim, I am ??P29

Shane McCarron: zakim, I am ??P29

14:03:52 <Zakim> +ShaneM; got it

Zakim IRC Bot: +ShaneM; got it

14:04:12 <manu> scribenick: manu

(Scribe set to Manu Sporny)

14:04:43 <manu> Manu: Any other agenda items? Shane, your @profile issue?

Manu Sporny: Any other agenda items? Shane, your @profile issue?

14:04:48 <manu> Shane: Not yet, Ivan isn't here. What about Vocabulary Expansion?

Shane McCarron: Not yet, Ivan isn't here. What about Vocabulary Expansion?

14:05:06 <manu> Gregg: Vocabulary Expansion is a parallel issue to @profile.

Gregg Kellogg: Vocabulary Expansion is a parallel issue to @profile.

14:05:20 <manu> Shane: Correct - @profile isn't the long pole in the tent anymore - Vocabulary Expansion is.

Shane McCarron: Correct - @profile isn't the long pole in the tent anymore - Vocabulary Expansion is.

14:05:38 <manu> Topic: Vocabulary Expansion Update

1. Vocabulary Expansion Update

14:05:52 <manu> Niklas: Gregg and I haven't coordinated yet - haven't had time - began writing some of the spec text.

Niklas Lindström: Gregg and I haven't coordinated yet - haven't had time - began writing some of the spec text.

14:06:09 <manu> Niklas: Looked at Ivan's text - administrative problem is access to CVS.

Niklas Lindström: Looked at Ivan's text - administrative problem is access to CVS.

14:06:32 <manu> Niklas: I could write the text and and mail it to the list?

Niklas Lindström: I could write the text and and mail it to the list?

14:07:07 <manu> Manu: Gregg has CVS access and adding spec language.

Manu Sporny: Gregg has CVS access and adding spec language.

14:07:07 <gkellogg> Gregg: I was going to start on it on my own... happy to take whatever Niklas has and work with that. Need some expository material, need that as well. Shane has the final say on spec text, of course.

Gregg Kellogg: I was going to start on it on my own... happy to take whatever Niklas has and work with that. Need some expository material, need that as well. Shane has the final say on spec text, of course. [ Scribe Assist by Gregg Kellogg ]

14:08:34 <manu> Niklas: Could we hack on it on github?

Niklas Lindström: Could we hack on it on github?

14:08:52 <manu> Manu: I don't think W3c would like that... just send the language to the mailing list, we'll discuss there - have Gregg integrate it.

Manu Sporny: I don't think W3c would like that... just send the language to the mailing list, we'll discuss there - have Gregg integrate it.

14:09:08 <MacTed> http://www.w3.org/2010/02/rdfa/wiki/Main_Page

Ted Thibodeau: http://www.w3.org/2010/02/rdfa/wiki/Main_Page

14:09:24 <MacTed> It's a wiki.  It's in w3.  It's a good place for collaborative text building...

Ted Thibodeau: It's a wiki. It's in w3. It's a good place for collaborative text building...

14:09:39 <manu> Niklas: Some issues that we could add to the Agenda - if we have the time, I'd like to take up dereferencing IRI in @vocab directly.

Niklas Lindström: Some issues that we could add to the Agenda - if we have the time, I'd like to take up dereferencing IRI in @vocab directly.

14:12:25 <manu> Topic: ISSUE-101: xsd:string coercion

2. ISSUE-101: xsd:string coercion

14:12:31 <manu> The issue is here: http://www.w3.org/2010/02/rdfa/track/issues/101

The issue is here: http://www.w3.org/2010/02/rdfa/track/issues/101

14:12:43 <manu> Started in this thread: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jun/0064.html

Started in this thread: http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jun/0064.html

14:13:47 <gkellogg> q+

Gregg Kellogg: q+

14:13:48 <Zakim> +scor

Zakim IRC Bot: +scor

14:14:00 <manu> Manu: Should we add spec text asking implementers change anything that is an xsd:string to a plain literal?

Manu Sporny: Should we add spec text asking implementers change anything that is an xsd:string to a plain literal?

14:14:28 <manu> Gregg: My read of their finding was a bit different - abstract model should use xsd:string datatype for plain literals w/o a language.

Gregg Kellogg: My read of their finding was a bit different - abstract model should use xsd:string datatype for plain literals w/o a language.

14:14:38 <manu> Gregg: Recent communication about how @lang might be handled.

Gregg Kellogg: Recent communication about how @lang might be handled.

14:14:46 <gkellogg> http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0048.html

Gregg Kellogg: http://lists.w3.org/Archives/Public/public-rdf-wg/2011Jul/0048.html

14:15:17 <manu> Gregg: One of the issues is how serializations should be managed. I think we do want to follow their lead to not create any extra confusion.

Gregg Kellogg: One of the issues is how serializations should be managed. I think we do want to follow their lead to not create any extra confusion.

14:15:27 <manu> Manu: Are you saying we need not do anything?

Manu Sporny: Are you saying we need not do anything?

14:15:53 <lindstream> q+

Niklas Lindström: q+

14:15:58 <manu> Gregg: No, we should note the changes to the abstract syntax in the spec - plain literals implicitly get a datatype string, when they're serialized, they're serialized w/o that datatype.

Gregg Kellogg: No, we should note the changes to the abstract syntax in the spec - plain literals implicitly get a datatype string, when they're serialized, they're serialized w/o that datatype.

14:16:00 <manu> ack gkellogg

ack gkellogg

14:16:49 <manu> Niklas: After reading what Ivan wrote about this - I agree w/ Ivan - the problem is that today RDF libraries differentiate between datatype literals and plain literals w/o language. The new semantic interpretation would be that they are datatyped literals w/ xsd:string.

Niklas Lindström: After reading what Ivan wrote about this - I agree w/ Ivan - the problem is that today RDF libraries differentiate between datatype literals and plain literals w/o language. The new semantic interpretation would be that they are datatyped literals w/ xsd:string.

14:17:41 <manu> Niklas: An RDF spec would say that every time you generate a datatype w/ a plain string - old style processors would serialize these things w/ "xsd:string" at the end... and new ones would serialize as plain literals.

Niklas Lindström: An RDF spec would say that every time you generate a datatype w/ a plain string - old style processors would serialize these things w/ "xsd:string" at the end... and new ones would serialize as plain literals.

14:17:48 <manu> Niklas: Real problem is integration w/ RDF libraries that may not have agreement between the parsers and the serializers.

Niklas Lindström: Real problem is integration w/ RDF libraries that may not have agreement between the parsers and the serializers.

14:17:55 <manu> ack lindstream

ack lindstream

14:19:12 <manu> Manu explains his understanding of the issue.

Manu explains his understanding of the issue.

14:20:02 <lindstream> q+

Niklas Lindström: q+

14:20:16 <manu> Gregg: I'm trying to figure out how this could happen - if you have mixed systems - like raptor/redland ... your parser is in the new style (generating xsd:string) then your serializer must be in the same new style (generating plain literal instead of typed literal w/ xsd:string).

Gregg Kellogg: I'm trying to figure out how this could happen - if you have mixed systems - like raptor/redland ... your parser is in the new style (generating xsd:string) then your serializer must be in the same new style (generating plain literal instead of typed literal w/ xsd:string).

14:20:42 <manu> Gregg: You could have a half-implemented issue there... what happens when parser is new style and serializer is old style?

Gregg Kellogg: You could have a half-implemented issue there... what happens when parser is new style and serializer is old style?

14:21:52 <manu> Niklas: Semantically, as the RDF WG is defining it - there is no longer a plain literal... if I send that data in-memory to another implementation... that could be an issue. We could create spec language for this - if you have an implementation, if you have something that differentiates between plain literals and xsd:string - do the new thing.

Niklas Lindström: Semantically, as the RDF WG is defining it - there is no longer a plain literal... if I send that data in-memory to another implementation... that could be an issue. We could create spec language for this - if you have an implementation, if you have something that differentiates between plain literals and xsd:string - do the new thing.

14:25:19 <manu> Gregg: The issue has to do w/ how you express the serialization.

Gregg Kellogg: The issue has to do w/ how you express the serialization.

14:25:55 <manu> Discussion about what RDFa Processors output - an RDF abstract model - or a serialized stream.

Discussion about what RDFa Processors output - an RDF abstract model - or a serialized stream.

14:25:59 <lindstream> q+

Niklas Lindström: q+

14:26:04 <manu> q+

q+

14:26:22 <manu> Shane: The issue is on the serialized output, not the model - because you don't really have access to the abstract model in many processors.

Shane McCarron: The issue is on the serialized output, not the model - because you don't really have access to the abstract model in many processors.

14:27:03 <manu> Niklas: There are two ways to express a string literals - when reasoned over these things are semantically equivalent. There is nothing wrong with a parser that differentiates between how it picked up the data during the parsing process.

Niklas Lindström: There are two ways to express a string literals - when reasoned over these things are semantically equivalent. There is nothing wrong with a parser that differentiates between how it picked up the data during the parsing process.

14:27:31 <manu> Niklas: Let's say that semantically, literals w/o datatype are actually literals w/ a datatype xsd:string.

Niklas Lindström: Let's say that semantically, literals w/o datatype are actually literals w/ a datatype xsd:string.

14:28:06 <manu> Niklas: This difference can be expressed in RDFa - we can use an empty @lang attribute or a datatype xsd:string... the syntactic difference should be taken into account w/ RDFa libraries if they support this difference.

Niklas Lindström: This difference can be expressed in RDFa - we can use an empty @lang attribute or a datatype xsd:string... the syntactic difference should be taken into account w/ RDFa libraries if they support this difference.

14:28:10 <gkellogg> RDF WG: "foo" and corresponding forms in other concrete syntaxes are syntactic sugar for "foo"^^xsd:string. In general, both forms MAY be used and represent identical literals in the abstract syntax.

Gregg Kellogg: RDF WG: "foo" and corresponding forms in other concrete syntaxes are syntactic sugar for "foo"^^xsd:string. In general, both forms MAY be used and represent identical literals in the abstract syntax.

14:28:30 <manu> Niklas: If not, they should always be the literal w/ xsd:string - we can't force them to pick one or the other if they only support one thing.

Niklas Lindström: If not, they should always be the literal w/ xsd:string - we can't force them to pick one or the other if they only support one thing.

14:29:18 <manu> Niklas: If they were to parse TURTLE, it wouldn't be wrong to preserve that a string was expressed as a plain literal and not an xsd:string in the model - it would be unnecessary semantically - nothing wrong w/ an RDFa parser to denote the syntactic differences.

Niklas Lindström: If they were to parse TURTLE, it wouldn't be wrong to preserve that a string was expressed as a plain literal and not an xsd:string in the model - it would be unnecessary semantically - nothing wrong w/ an RDFa parser to denote the syntactic differences.

14:29:34 <manu> Niklas: But there is no longer a semantic difference.

Niklas Lindström: But there is no longer a semantic difference.

14:30:15 <manu> Manu: So, there is no change I need to make to my parser?

Manu Sporny: So, there is no change I need to make to my parser?

14:30:32 <gkellogg> q+ to discuss Turtle spec language

Gregg Kellogg: q+ to discuss Turtle spec language

14:30:36 <manu> ack lindstream

ack lindstream

14:30:38 <manu> ack manu

ack manu

14:31:33 <manu> Manu: I think the real problem is that two processors could generate different triples from one another.

Manu Sporny: I think the real problem is that two processors could generate different triples from one another.

14:31:37 <Zakim> - +358.405.25aaaa

Zakim IRC Bot: - +358.405.25aaaa

14:32:05 <manu> Niklas: Libraries/serializers are no longer separate - this may cause implementation issues going forward.

Niklas Lindström: Libraries/serializers are no longer separate - this may cause implementation issues going forward.

14:32:28 <manu> Niklas: That's the problem the RDF WG are facing... they can only preserve syntactic difference for libraries that maintain the difference in memory.

Niklas Lindström: That's the problem the RDF WG are facing... they can only preserve syntactic difference for libraries that maintain the difference in memory.

14:32:31 <manu> ack gkellogg

ack gkellogg

14:32:31 <Zakim> gkellogg, you wanted to discuss Turtle spec language

Zakim IRC Bot: gkellogg, you wanted to discuss Turtle spec language

14:33:12 <gkellogg> Literals have either a language suffix or a datatype IRI but not both. Languages are indicated by appending the simple literal with @ and the language tag. Datatype IRIs similarly append ^^ followed by any legal IRI form (full or prefixed) as described above to give the datatype IRI. Literals may be written without either a language tag or a datatype IRI as a shortcut for a literal with the type xsd:string.

Gregg Kellogg: Literals have either a language suffix or a datatype IRI but not both. Languages are indicated by appending the simple literal with @ and the language tag. Datatype IRIs similarly append ^^ followed by any legal IRI form (full or prefixed) as described above to give the datatype IRI. Literals may be written without either a language tag or a datatype IRI as a shortcut for a literal with the type xsd:string.

14:33:15 <manu> Gregg: Looking at latest TURTLE spec, the way they approach that is that they say that literals may be written plain literals w/o datatype and language.

Gregg Kellogg: Looking at latest TURTLE spec, the way they approach that is that they say that literals may be written plain literals w/o datatype and language.

14:35:13 <manu> Manu: My concern is having RDFa Processors that generate different triples - are they conformant even if they generate two types of triples?

Manu Sporny: My concern is having RDFa Processors that generate different triples - are they conformant even if they generate two types of triples?

14:36:55 <manu> Niklas: I see the concern - the triples aren't different anymore at the serialization level.

Niklas Lindström: I see the concern - the triples aren't different anymore at the serialization level.

14:37:13 <manu> Manu: I see this approach creating bugs...

Manu Sporny: I see this approach creating bugs...

14:38:21 <manu> Manu: Who would update their implementations based on this language?

Manu Sporny: Who would update their implementations based on this language?

14:38:24 <manu> Niklas: I would

Niklas Lindström: I would

14:38:30 <manu> Gregg: So would I

Gregg Kellogg: So would I

14:38:30 <manu> Manu: I don't think I'd do anything.

Manu Sporny: I don't think I'd do anything.

14:39:01 <manu> Niklas: I would expect that any sort of serialization diffs would disappear when SPARQL serializations changed.

Niklas Lindström: I would expect that any sort of serialization diffs would disappear when SPARQL serializations changed.

14:39:22 <manu> Shane: I don't know if I'd make any changes.

Shane McCarron: I don't know if I'd make any changes.

14:40:22 <manu> Shane: Making us change plain literals to generate xsd:strings now is a backwards-incompatible change.

Shane McCarron: Making us change plain literals to generate xsd:strings now is a backwards-incompatible change.

14:40:44 <manu> Gregg: it would be valid to take xsd:string tagged literals and represent them internally as plain literals.

Gregg Kellogg: it would be valid to take xsd:string tagged literals and represent them internally as plain literals.

14:41:29 <manu> Gregg: this is a phantom issue - abstract syntax is not directly visible in RDF API, is it? If we add a test to the test suite - one plain and one tagged w/ xsd:string - what would the test be for that? What would the SPARQL do?

Gregg Kellogg: this is a phantom issue - abstract syntax is not directly visible in RDF API, is it? If we add a test to the test suite - one plain and one tagged w/ xsd:string - what would the test be for that? What would the SPARQL do?

14:42:12 <manu> Manu: Doesn't RDF API / RDF Interfaces operate on the abstract model? My librdfa processor expresses triples via a callback in abstract model space, not serialization space.

Manu Sporny: Doesn't RDF API / RDF Interfaces operate on the abstract model? My librdfa processor expresses triples via a callback in abstract model space, not serialization space.

14:44:39 <manu> Manu explains how this may impact librdfa implementation - would remove an object type of OBJECT_TYPE_PLAIN_LITERAL, and only have OT_IRI, OT_TYPED, OT_PLAIN_LITERAL_WITH_LANGUAGE.

Manu explains how this may impact librdfa implementation - would remove an object type of OBJECT_TYPE_PLAIN_LITERAL, and only have OT_IRI, OT_TYPED, OT_PLAIN_LITERAL_WITH_LANGUAGE.

14:45:16 <manu> Shane: Abstract model is that of a plain literal w/o datatype tag - still leads to backwards compatibility issue - xsd:string was never intended to be treated differently than plain literal.

Shane McCarron: Abstract model is that of a plain literal w/o datatype tag - still leads to backwards compatibility issue - xsd:string was never intended to be treated differently than plain literal.

14:45:51 <manu> Gregg: I think we should ask for some feedback from the WG.

Gregg Kellogg: I think we should ask for some feedback from the WG.

14:46:11 <manu> ACTION: Gregg to contact Richard in RDF WG about xsd:string coercion.

ACTION: Gregg to contact Richard in RDF WG about xsd:string coercion.

14:46:12 <trackbot> Created ACTION-89 - Contact Richard in RDF WG about xsd:string coercion. [on Gregg Kellogg - due 2011-08-25].

Trackbot IRC Bot: Created ACTION-89 - Contact Richard in RDF WG about xsd:string coercion. [on Gregg Kellogg - due 2011-08-25].

14:46:40 <manu> Topic: ISSUE-102: @prefix limit

3. ISSUE-102: @prefix limit

14:46:50 <manu> Issue is here: http://www.w3.org/2010/02/rdfa/track/issues/102

Issue is here: http://www.w3.org/2010/02/rdfa/track/issues/102

14:48:10 <manu> Raised here http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0044.html

Raised here http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jul/0044.html

14:49:54 <ShaneM> q+ to propose we just close this issue.

Shane McCarron: q+ to propose we just close this issue.

14:50:32 <manu> Manu explain the issue

Manu explain the issue

14:50:36 <manu> ack ShaneM

ack ShaneM

14:50:36 <Zakim> ShaneM, you wanted to propose we just close this issue.

Zakim IRC Bot: ShaneM, you wanted to propose we just close this issue.

14:51:22 <manu> Shane: We have to allow prefix everywhere - we should tell people about this issue - there is nothing we can solve here. We can put in warnings, best practices, but no normative spec change we can make.

Shane McCarron: We have to allow prefix everywhere - we should tell people about this issue - there is nothing we can solve here. We can put in warnings, best practices, but no normative spec change we can make.

14:52:18 <lindstream> q+

Niklas Lindström: q+

14:52:28 <manu> Gregg: Yes, we should specify a best practice.

Gregg Kellogg: Yes, we should specify a best practice.

14:52:41 <manu> Niklas: yes, agree - close it - add best practices to the spec.

Niklas Lindström: yes, agree - close it - add best practices to the spec.

14:52:44 <MacTed> +1 best practices guidance, and warnings of what may happen if those are not followed...

Ted Thibodeau: +1 best practices guidance, and warnings of what may happen if those are not followed...

14:52:50 <manu> ack lindstream

ack lindstream

14:54:32 <manu> Niklas: The real problem might be the content type sniffing issue - RDFa in XHTML context - where encoding is done at top - UTF-8 by default. This hasn't been an issue for us. Advice around that would be reasonable. Deprecate @prefix altogether, go a different route - that doesn't seem viable.

Niklas Lindström: The real problem might be the content type sniffing issue - RDFa in XHTML context - where encoding is done at top - UTF-8 by default. This hasn't been an issue for us. Advice around that would be reasonable. Deprecate @prefix altogether, go a different route - that doesn't seem viable.

14:56:19 <gkellogg> q+

Gregg Kellogg: q+

14:56:29 <manu> ack gkellogg

ack gkellogg

14:57:23 <manu> Gregg: If I look at some of my own implementations - it's not practical to put prefixes on root element or BODY... ends up going on some chunk that are output. Issue may be that the same prefix not be re-defined. @prefixes should be created at some well-defined level.

Gregg Kellogg: If I look at some of my own implementations - it's not practical to put prefixes on root element or BODY... ends up going on some chunk that are output. Issue may be that the same prefix not be re-defined. @prefixes should be created at some well-defined level.

14:57:35 <manu> Gregg: the real copy-paste problem might be that they're re-defined or not defined at all.

Gregg Kellogg: the real copy-paste problem might be that they're re-defined or not defined at all.

14:57:45 <ShaneM> Note - If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations may have trouble determining the encoding of the document.

Shane McCarron: Note - If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations may have trouble determining the encoding of the document.

14:58:08 <manu> Gregg: We also found when trying to parse HTML documents - we don't know whether they're RDFa or Microdata - you can't do it at the top of the document - you have to parse the entire document to know whether it is RDFa or Microdata or both.

Gregg Kellogg: We also found when trying to parse HTML documents - we don't know whether they're RDFa or Microdata - you can't do it at the top of the document - you have to parse the entire document to know whether it is RDFa or Microdata or both.

14:59:18 <MacTed> q+

Ted Thibodeau: q+

14:59:21 <MacTed> Zakim, unmute me

Ted Thibodeau: Zakim, unmute me

14:59:32 <Zakim> MacTed should no longer be muted

Zakim IRC Bot: MacTed should no longer be muted

15:00:00 <manu> Ted: Add something to talk about what happens when you don't do this - best practices often fail to tell you why something is a best practice.

Ted Thibodeau: Add something to talk about what happens when you don't do this - best practices often fail to tell you why something is a best practice.

15:00:22 <manu> Gregg: Add bit about grouping @prefix in some logical fashion in the document.

Gregg Kellogg: Add bit about grouping @prefix in some logical fashion in the document.

15:00:32 <manu> PROPOSAL: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements.

PROPOSED: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements.

15:00:35 <ShaneM> Note - If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations that use so-called 'content sniffing' may have trouble accurately determining the encoding of the document.

Shane McCarron: Note - If a document uses an encoding other than UTF-8, and the document declares many prefix mappings, the document SHOULD NOT declare all of those prefixes on the root element because implementations that use so-called 'content sniffing' may have trouble accurately determining the encoding of the document.

15:00:36 <ShaneM> +1

Shane McCarron: +1

15:00:37 <manu> Manu: +1

Manu Sporny: +1

15:00:39 <gkellogg> +1

Gregg Kellogg: +1

15:00:40 <lindstream> +1

Niklas Lindström: +1

15:00:42 <MacTed> +1

Ted Thibodeau: +1

15:00:44 <scor> +1

Stéphane Corlosquet: +1

15:00:53 <manu> RESOLVED: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements.

RESOLVED: Close ISSUE-120: @prefix limit - no normative changes to the spec. Add best practices section about content encoding, browser content encoding sniffing, and @prefix on the root and HEAD elements.

15:02:00 <manu> PROPOSAL: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document.

PROPOSED: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document.

15:02:17 <gkellogg> +1

Gregg Kellogg: +1

15:02:18 <lindstream> +1

Niklas Lindström: +1

15:02:19 <manu> Manu: +1

Manu Sporny: +1

15:02:20 <MacTed> +1

Ted Thibodeau: +1

15:02:23 <ShaneM> +1

Shane McCarron: +1

15:03:09 <manu> RESOLVED: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document.

RESOLVED: Add best practice specifying that @prefix declarations should be grouped together in some logical fashion and shouldn't be spread haphazardly across the document. The same prefix should not be defined w/ two different meanings in the same document.

15:03:49 <ShaneM> ACTION: Shane to add test about @prefix use.

ACTION: Shane to add test about @prefix use.

15:03:49 <trackbot> Created ACTION-90 - Add test about @prefix use. [on Shane McCarron - due 2011-08-25].

Trackbot IRC Bot: Created ACTION-90 - Add test about @prefix use. [on Shane McCarron - due 2011-08-25].



Formatted by CommonScribe


This revision (#1) generated 2011-08-18 15:47:20 UTC by 'msporny', comments: 'Minor fixes/cleanups.'