13:40:30 RRSAgent has joined #rdfa 13:40:30 logging to http://www.w3.org/2010/07/08-rdfa-irc 13:42:28 manu has changed the topic to: RDFa WG Telecon Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0020.html (manu) 13:42:37 trackbot, prepare telecon 13:42:40 RRSAgent, make logs world 13:42:42 Zakim, this will be 7332 13:42:42 ok, trackbot; I see SW_RDFa()10:00AM scheduled to start in 18 minutes 13:42:43 Meeting: RDFa Working Group Teleconference 13:42:43 Date: 08 July 2010 13:43:29 Agenda: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0020.html 13:43:32 Chair: Manu 13:44:14 Scribe: Steven 13:44:35 SCribenick: Steven_ 13:44:42 s/SC/Sc/ 13:52:28 tinkster has joined #rdfa 13:58:41 SW_RDFa()10:00AM has now started 13:58:50 + +44.785.583.aaaa 13:58:54 zakim, dial steven-617 13:58:54 ok, Steven_; the call is being made 13:58:55 - +44.785.583.aaaa 13:58:55 + +44.785.583.aaaa 13:58:56 +Steven 13:59:06 Zakim, aaaa is me 13:59:06 +tinkster; got it 13:59:10 +[IPcaller] 13:59:11 zakim, dial ivan-voip 13:59:11 ok, ivan; the call is being made 13:59:12 +Ivan 13:59:28 zakim, I am IPcaller (not that you care) 13:59:28 I don't understand 'I am IPcaller (not that you care)', manu 13:59:42 zakim, [IP is manu 13:59:42 +manu; got it 14:00:05 Benjamin has joined #rdfa 14:00:09 zakim, who is on the call? 14:00:09 On the phone I see tinkster, Steven, manu, Ivan 14:00:11 ShaneM has joined #rdfa 14:00:29 + +1.612.217.aabb 14:00:35 zakim, aabb is ShaneM 14:00:35 +ShaneM; got it 14:01:43 + +49.631.205.75.aacc 14:01:55 zakim, aacc is Benjamin 14:01:55 +Benjamin; got it 14:02:42 zakim, who is here? 14:02:43 On the phone I see tinkster, Steven, manu, Ivan, ShaneM, Benjamin 14:02:44 On IRC I see ShaneM, Benjamin, tinkster, RRSAgent, trackbot, Zakim, manu, Steven_, ivan, markbirbeck 14:03:04 Jeez..."All circuits are busy now." 14:03:31 .me DId you see the new UK number Mark? 14:03:40 that's the one. :( 14:03:47 Will dial US. 14:04:36 Topic: ISSUE-15: @version attribute in HTML5 (on Manu) http://www.w3.org/2010/02/rdfa/track/issues/15 14:05:21 Manu: @version was taken out of HTML5 14:05:38 ... so HTML5+RDFa spec defines it 14:05:50 ... problem though, see email 14:05:52 q+ 14:06:02 Explanation of issues with @version: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Jul/0036.html 14:06:12 +Mark_Birbeck 14:06:15 ack ivan 14:06:17 Manu: Toby has a good proposal 14:06:21 q+ to respond to Ivan (assuming he will talk about his message to the mailing list) 14:06:44 Ivan: I know that @version is in RDFa 1.0, was informational, had no effect on processor, not required 14:06:58 ... so its role is minimal 14:07:05 ... do we need to make it more serious? 14:07:17 q+ to discuss @version history 14:07:42 Ivan: What is the intention? 14:07:58 ... to inform the world that this is RDFa? 14:08:06 ... what's the goal? 14:08:08 ack tinkster 14:08:08 tinkster, you wanted to respond to Ivan (assuming he will talk about his message to the mailing list) 14:08:36 Toby: Semantics of @version is to say which version of RDFa is used for authoring 14:08:41 ack shanem 14:08:41 ShaneM, you wanted to discuss @version history 14:08:45 ... and therefore for processing 14:09:35 Shane: I agree with Toby'the WG decided to elevate the visibility of @version, it has always been in XHTML, and each version of XHTML has a different version 14:09:54 q+ 14:09:54 ... we made it more visibility because DOCTYPES were disappearing 14:10:08 I was more saying that processors can process RDFa according to whatever version they like; but @version tells processors which version the author intended/"guarantees will work". 14:10:18 ... and we needed a way to say which version was being used 14:10:20 q+ 14:10:38 ... we should have stuck with DOCTYPES, but we didn't 14:10:53 ack ivan 14:11:18 Ivan: Understood. If @version is dropped from HTML5, what alternative is there in HTML5? 14:11:23 q+ to describe HTML5's announcement mechanism 14:11:27 ... for announcing anything about the document 14:11:31 HTML5 intentionally has no versioning information. 14:11:55 http://www.w3.org/html/wg/tracker/issues/4 14:11:59 Ivan: we used the existing announcement mechanism, we should use whatever the host gives us 14:12:08 ... in SVG there is no version 14:12:17 ... what should SVG do? 14:12:30 ack markbirbekc 14:12:32 ack markbirbeck 14:13:05 Mark: DOCTYPE wouldn't have been enough at the time, becauase we wanted to say "this document really does contain RDFa" 14:13:16 hmm - interesting take 14:13:19 ... so why do we want an announcement mechanism? 14:13:39 ... there seems to be a general problem 14:13:50 ... maybe we've used @version in a way not intended 14:14:03 ... you wouldn't announce SVG at the top 14:14:07 q+ 14:14:19 SVG does actually have @version on the root element. Valid values are '1.0', '1.1' and '1.2'. Also @baseProfile for flavours within each version. 14:14:39 Mark: Why bother with announcing? 14:14:52 ... does it save anything? 14:14:53 ack manu 14:14:53 manu, you wanted to describe HTML5's announcement mechanism 14:15:24 tinkster: true, but I do not think you would be allowed to add an RDFa value to the svg @version attribute 14:15:29 Mark: HTML5 doesn't say that the doc contains SVG 14:15:37 I thought Ivan was referring to RDFa in SVG. 14:15:55 tinkster: yes I was. But I do not think we could use that 14:16:05 Manu: If you don't have access to the head of a document, you're out of luck anyway 14:16:20 We can't use SVG's attribute; not without breaking the SVG schema. 14:16:24 ack Steven_ 14:16:24 s/tinkster:/tinkster, 14:17:13 q+ 14:17:47 Steven_: My recollection is that TAG insisted we have a mechanism. 14:18:04 ack ivan 14:18:05 ...They felt that there should be some notion of 'what the author intended'. 14:18:09 q+ to discuss author intent 14:18:22 Steven: Since you could extract triples from documents that weren't intended to have RDFa in them 14:18:36 ...Did they expect their mark-up to be processed by an RDFa processor? If not, then we shouldn't do it. :) 14:18:56 Ivan: True enough, but @version is not required for processors to work 14:19:11 q+ 14:19:14 ack shanem 14:19:14 ShaneM, you wanted to discuss author intent 14:19:22 Shane: That's right 14:19:40 ... Steven you're right that the TAG were calling for this, and frankly I don't care 14:20:09 ... there's a different school of thought that says we can process a document jsut how we want, regardless of the author's intent 14:20:13 One can extract triples from VCARD or Atom if you like; doesn't mean that the author intended for it to happen. 14:20:17 s/jsut/just/ 14:20:26 ack markbirbeck 14:20:29 Shane: So I agree, just remove it 14:21:05 Mark: Indeed it was the TAG, we were all thinking at the time, this was a sop, but we made it optional to allow the processing of documents without it. 14:21:24 ... so do we just move on now? 14:21:45 ... We didn't deprecate version, so it's not our fault 14:21:53 q+ to discuss deprecation 14:22:00 I think @version is a very important attribute. just not for this purpose 14:22:02 not our fault, guv. 14:22:03 ... We don't want it bgack, it's deprecated, so that's that 14:22:06 ack manu 14:22:06 manu, you wanted to discuss deprecation 14:22:15 s/bg/b 14:22:31 Manu: We'll get a community of people asking us how to do backwards compatibility 14:22:38 q+ 14:23:14 It's possible to do version detection even if we drop it: RDFa 1.0 has @version="XHTML+RDFa 1.0" and RDFa 1.1 does not. 14:23:18 q+ to discuss supporting 1.0 and 1.1. 14:23:21 ... so if we deprecate, what do we say happens? 14:23:49 ack ivan 14:24:01 ... What does a processor do? Does this make RDFa 1.0 docs RDFa 1.1? 14:24:16 Ivan: @version had no effect on the processor in RDFa 1.0 14:24:35 q+ to discuss the effect of @version 14:24:36 ... so we just don't use it anymore 14:24:59 ... I don't see a problem 14:25:04 ack shanem 14:25:04 ShaneM, you wanted to discuss supporting 1.0 and 1.1. 14:25:07 Shane: I disagree 14:25:14 ... @version does have an effect 14:25:33 ... the effect is only apprent in the presence of other RDFa dialects 14:25:50 s/appr/appar/ 14:26:16 q+ 14:26:20 Shane: If version is present, and says 1.0, then the processor has to process it as 1.0 14:26:42 ack manu 14:26:42 manu, you wanted to discuss the effect of @version 14:27:02 my processor has branches too 14:27:06 Manu: I agre, I change processing in my processor based on @version 14:27:11 s/agre/agree/ 14:27:27 ack ivan 14:27:35 ... and bail on a version that I don't know how to process 14:27:37 But I did change my processor so the default is 1.1 14:27:54 Ivan: I don't do that; and as far as I know any RDFa 1.0 is valid 1.1 14:28:01 while a 1.0 file is valid 1.1, ytou will get different triples because of XMLLiteral 14:28:03 q+ to discuss backwards compatibility 14:28:09 ... we can do more in 1.1, but we cannot do less. 14:28:32 ... well, OK I admit XML literal is different, but it is not used much 14:28:49 ... so I don't see a reason to require a switch 14:28:56 I dont think we said that 14:29:23 Manu: there are other differences too, upper and lower case, [others] 14:29:38 q+ 14:29:49 (my processor did it because there was an errata that said we should expect that to happen) 14:29:50 we said that rel=License is lowercased in the 1.0 errata 14:30:08 ... I'm not trying to make it seem like I think there should be a branching switch, but if we do this we will change the semantics of RDFa 1.0 docs 14:30:21 ack manu 14:30:21 manu, you wanted to discuss backwards compatibility 14:30:24 ack markbirbeck 14:30:58 Mark: You may get less triples with 1.0 14:31:31 q+ to discuss best effort 14:31:36 ... I do think it is legitimate to do a best effort rather than bailing 14:32:27 actually - @profile in a 1.0 parser might get different triples than a 1.1 document in which there was an @profile but it was unresolvable, for example. 14:32:29 ack manu 14:32:29 manu, you wanted to discuss best effort 14:33:01 Manu: I do agree that processors should do a best effort, and we seem to be concluding that @version should have no effect 14:33:25 ... agree? 14:33:28 Ivan: Yes 14:33:30 +q 14:33:33 ack ShaneM 14:33:35 +1 14:33:53 Ivan: Now that core is separate from the rest, @version doesn't exist in core anymore 14:34:01 note that there still must be an @version in XHTML+RDFa 1.1... M12N requries it. 14:34:11 Manu: Then we deprecate @version? Or remove it? 14:34:15 q+ 14:34:24 If RDFa 2.0 needs to be backwards compatible, they can introduce profile="urn:w3c:rdfa:2.0" on the root element. (This is unresolvable so will prevent triples being generated by 1.1 parsers.) 14:34:26 ... Should a processor ignore it? 14:34:33 q+ to discuss removal 14:34:36 ack ivan 14:34:36 s/compatible/incompatible/ 14:35:20 Ivan: Depends. Core doesn't mention @version and shouldn't. In places where it is mentioned it should be deprecated, and for HTML5 it shouldn;t be there at all. 14:35:22 q+ 14:35:32 s/;/' 14:35:43 ack ShaneM 14:35:43 ShaneM, you wanted to discuss removal 14:36:14 SHane: I agree with Ivan, but in XHTML+RDFa 1.1 we can't mark the attribute as deprecated, but taken out of conformance requirements 14:36:20 s/SH/Sh/ 14:36:31 ack shanem 14:36:33 ack steven_ 14:38:07 Steven: The fact that it's not in HTML5 doesn't mean it has to be removed. HTML5 leave attributes it doesn't kno in the DOM 14:38:21 s/kno/know/ 14:38:31 Manu: [scribe missed] 14:38:42 "For the avoidance of doubt, an RDFa Processor MUST NOT use the value of @version to effect its processing." 14:39:21 Manu: Proposal: Deprecate @version in XHTML+RDFa 1.1 14:39:27 PROPOSAL: Deprecate the use of the value of @version in XHTML+RDFa 1.1. State that @version, as it pertains to RDFa, MUST be ignored by all RDFa Processors. 14:39:57 Steven: MUST or SHOULD? 14:40:16 q+ 14:40:27 Manu: MUST I think 14:40:35 ack tinkster 14:40:36 I agree with MUST 14:40:59 Toby: The problem with that is that we didn't say it in RDFa 1.0 14:41:27 ... so a processor could still honour it 14:43:27 Manu: All you have to do is be conformant with 1.0 14:43:41 ... Why would they dispatch a 1.0 processor on it? 14:44:16 Toby: You can't forbid processors looking at version because it was in 1.0 14:44:40 Manu: Does this affect the proposal? 14:44:50 Steven: I'm OK with SHOULD 14:44:59 PROPOSAL: Deprecate the use of the value of @version in XHTML+RDFa 1.1. State that @version, as it pertains to RDFa, be ignored by all RDFa Processors. 14:45:13 +1 14:45:15 +1 14:45:18 Manu: Let's discuss MUST vs SHOULD on the mailing list 14:45:18 +1 14:45:18 +1 14:45:21 +1 14:45:41 +1 14:45:44 +1 14:45:45 RESOLVED: Deprecate the use of the value of @version in XHTML+RDFa 1.1. State that @version, as it pertains to RDFa, be ignored by all RDFa Processors. 14:46:12 Manu: There's no @version in core right? 14:46:14 Shane: No 14:46:47 Manu: And then in HTML5 version, we can remove the language 14:46:58 "For the avoidance of doubt, an RDFa Processor MUST NOT use the value of @version to effect its processing." 14:47:16 s/effect/affect/ 14:47:21 PROPOSAL: Remove mention of @version in HTML+RDFa 1.1 spec. State that @version, as it pertains to RDFa, be ignored by all RDFa Processors. 14:47:48 +1 14:47:51 +1 14:47:53 +1 14:47:54 +1 14:48:00 +1 14:48:11 Manu: Again decide on MUST vs SHOULD on mailing list 14:48:24 +1 14:48:28 zakim, mute me 14:48:28 Ivan should now be muted 14:48:50 +1 14:49:01 RESOLVED: Remove mention of @version in HTML+RDFa 1.1 spec. State that @version, as it pertains to RDFa, be ignored by all RDFa Processors. 14:49:04 s/HTML/XHTML/ 14:49:31 Topic: ISSUE-24: Case-sensitive terms in HTML5 (on Shane) http://www.w3.org/2010/02/rdfa/track/issues/24 14:49:37 Manu: Is this already resolved? 14:49:51 This reminds me of the famous Oscar Wilde quote, where he says he'd had a busy day; he'd put a comma in, and then taken it out again. 14:50:12 Shane: We said many things, I don't think we resolved it 14:50:47 zakim, unmute me 14:50:47 Ivan should no longer be muted 14:51:18 q+ 14:51:19 Manu: So should we force all values in rel and rev to lower case? 14:51:21 q+ 14:51:23 ack ivan 14:51:42 *All* values? what about foaf:primaryTopic? 14:51:49 rdfs:seeAlso? 14:51:55 Ivan: Do you mean all rev and rel terms in the default, or including my own 14:51:58 foaf:workplaceHomepage 14:52:00 Manu: all 14:52:03 dc:conformsTo 14:52:05 TERM == NCNAME 14:52:14 ... but TERMs, things without colons 14:52:20 q- 14:52:29 @vocab='dc URL' rel=''conformsTo" 14:52:36 OK, for terms it's doable. 14:52:46 Ivan: THis would stop me having TERMS that matched the foaf predicates 14:52:51 s/TH/Th/ 14:52:55 The term would be case-insensitive; the expansion would be case-preserving. 14:53:21 Shane: You couldn't do what I just typed; that would be bad 14:53:44 Ivan: Correct 14:53:51 ... so we cannot do this 14:54:14 Manu: Right, so we do a case insensitive match on terms in HTML vocab 14:54:34 Ivan: Unless they are redefined 14:54:45 ... I could redefine license 14:55:01 Manu: Hmmm 14:55:29 Ivan: So we may be forced to say which set of terms are case insensitive or not 14:55:35 TERMs in the xhv: vocab could be required to be case insensitive 14:55:39 Manu: Hmmm 14:55:58 (My processor is able to keep track of case-sensitive and case-insensitive terms and prefixes simultaneously.) 14:56:33 Shane: I agree that you're right that you can redefine, but the processor would know that 14:56:48 ... but the things in xhv: vocab can be defined to be case insensitive 14:57:17 ... in whatever context it is brought in 14:57:25 This seems different from 1.0. 14:57:27 ... and mapped to lowercase 14:57:50 ... except, wait, the ARIA roles are NOT case insensitive. Oh crap! 14:57:53 rel="License" is mapped to lowercase in 1.0, but rel=":License" is not IIRC. 14:58:17 They preserve case. 14:58:24 Manu: I expect that the HTML5 processor proeserves case 14:58:32 s/oe/e/ 14:58:42 Manu: If they do we may need to rethink. 14:58:49 Topic: AOB 14:59:09 Shane: Modularization 1.1 PER should be going to Rec soon, affects us only slightly 14:59:27 ... XHTML 1.1 will then follow, adding @lang 14:59:42 ... which will affect us eventually 14:59:56 ... we don't have to do anything, but we have a dependency 15:00:05 bye all! 15:00:09 Manu: Thanks! Call next week. 15:00:10 zakim, bye 15:00:13 -Mark_Birbeck 15:00:15 Zakim has left #rdfa 15:00:16 zakim, drop me 15:00:17 leaving. As of this point the attendees were +44.785.583.aaaa, Steven, tinkster, [IPcaller], Ivan, manu, +1.612.217.aabb, ShaneM, +49.631.205.75.aacc, Benjamin, Mark_Birbeck 15:00:20 [SDJOURN] 15:00:27 s/S/A/ 15:00:35 sorry 15:09:29 I'm trying to understand this last issue; does anyone know where in HTML 5 it says that one cannot rely on the case of the tokens in the @rel attribute? 15:10:58 Oscar Wilde on the version attribute: http://www.quotationspage.com/quote/26788.html 15:11:28 hehe :) 15:12:01 markbirbeck: In HTML4, rel values were case insensitive. 15:12:28 HTML5 is supposed to be backwards compatible with HTML4 and thus it is assumed that they're case insensitive in HTML5 as well. 15:12:41 However, nobody has presented any spec text or done tests to see if this is the case. 15:13:02 so, this may be a good example of the implementations deviating from the spec 15:13:34 Well, to be more precise, it's the *link types* that are case-insensitive. 15:13:45 yes, exactly right. 15:13:58 So there's no problem with allowing someone to write "Next" or "next". 15:14:11 But that doesn't mean all @rel values should be case-insensitive. 15:15:01 so, the question is - should we generate a triple for rel="LiCeNsE" in HTML+RDFa 1.1? 15:15:09 We only need to be backwards-compatible on the tokens referred to in HTML 4.01. 15:15:18 No. :) 15:15:38 But for rel="NeXt"...yes. 15:15:40 I agree - but if we say No, what's the reasoning? 15:15:50 ah, sorry 15:16:03 I keep forgetting that rel="license" isn't in HTML 4.01 as a Link Type 15:16:07 (I think?) 15:16:10 No, it's not. 15:17:36 So, this is what I was trying to get at on the phone... we make case insensitivity only apply to HTML 4.01 terms. 15:17:45 s/terms/Link Types/ 15:18:18 but there is a parallel issue - are all @rel/@rev values treated in a case-insensitive manner? 15:18:23 I think the answer to that is no 15:18:30 and in fact, I think case is preserved for all rel/rev values. 15:18:39 but I haven't done the tests to see if that's the case. 15:18:41 Sorry...I thought HTML 5 did exact matching, but it doesn't (just re-read it). 15:19:08 Any link type that doesn't contain a colon must be compared case-insensitively. 15:19:34 right, which screws us 15:19:54 well, kind-of 15:19:58 I missed the point as to why that screws us, though...sorry. :( 15:20:01 it makes it confusing... 15:21:04 so, if we have Conforms to Foo 15:21:27 can we retrieve the value of @rel from an HTML5-built DOM, preserving the case? 15:21:37 or does the HTML5-built DOM lowercase "conformsTo"? 15:21:50 because if it forces "conformsTo" to lowercase, we're screwed. 15:22:04 I don't see anything that indicates it changes the values in the attributes. 15:22:20 because the predicate that is generated is "http://purl.org/dc/terms/conformsto" and not "http://purl.org/dc/terms/conformsTo" 15:22:25 I'm reading it that authors are free to type what they like. 15:22:46 right, that's my understanding as well 15:22:58 but nobody has tested it... 15:23:31 (this is also confusing because there are multiple things we're talking about) 15:23:41 I don't see anything in the pre-processing steps that would even hint at that (just break on space boundaries). 15:24:04 And also, the fact that anything with a colon in *is* case-sensitive would imply that they are not going to mung the attribute values. 15:24:39 yes, but why would you say that if /all/ values are case-sensitive? 15:25:04 why mention that values with a colon are case sensitive? Does that mean that values without a colon aren't case sensitive? 15:25:04 I'm not with you...all values aren't case-sensitive, are they? 15:25:32 That's what I'm saying - I think that all values /are/ case-sensitive. 15:25:37 Yes, that's what I said earlier...the point that I missed when I first read it: 15:25:40 "The link types that contain no U+003A COLON characters (:), including all those defined in this specification, are ASCII case-insensitive values, and must be compared as such." 15:25:51 "Thus, rel="next" is the same as rel="NEXT"." 15:26:07 as far as they are /compared/ yes. 15:26:15 So there are two things: comparison and what's stored in the DOM. 15:26:37 Yes, I see that, but I'm not seeing anything that effects the DOM. 15:26:42 As far as comparison is concerned - rel="next" and rel="NeXt" are the same. 15:26:44 (In the spec...) 15:27:39 You realise that this only matters to us if we have this default namespace thing? 15:27:53 @vocab... 15:27:59 as far as what's stored in the DOM: Can "next" be stored in the DOM as a value for @rel, can "NeXt" be stored in the DOM as a value for @rel? 15:28:37 Well, the thing is that the spec doesn't say which round things are, so I really doubt that they can mung the value. 15:28:56 yes, exactly 15:29:01 I don't think that they can munge the value. 15:29:07 If they said that everything is equivalent to the upper-case version (for example) then you could at a push convert the value to UC. 15:29:15 and if they can't munge the value, both HTML5 and XHTML5 are case sensitive. 15:29:18 which means we're good. 15:29:35 But the spec only says that "abc" == "aBc" == "aBC" .... 15:29:58 It doesn't say that they are all equivalent to "ABC". 15:30:34 I don't follow... they are all equivalent to "ABC" aren't they? 15:30:54 Comparison: "abc" == "aBc" == "aBC" == "ABC" 15:31:06 Well, only insofar as they are also all equivalent to "abc", and they are all equivalent to "aBc". 15:31:16 but in the DOM, they're stored as: "abc", "aBc", "aBC", "ABC" 15:31:30 I.e., they are all equivalent to each other, but there is no lingua franca, so to speak. 15:31:49 So, here's what I think affects RDFa 15:32:04 well, both affect RDFa, but in different ways. 15:32:04 I.e., the spec doesn't say they are all equivalent to 'x', it just says they are all equivalent to each other. 15:32:55 There's a world of difference between: 15:32:56 This is how Comparison (equivalence) affects RDFa: We MUST generate triples for NeXT, PREV, inDEx, etc. 15:32:58 "abc" == "aBc" == "aBC" == "ABC" 15:33:00 and: 15:33:39 ("abc" == "ABC") + ("aBc" == "ABC") + ("aBC" == "ABC") 15:34:03 Ok...we can generate those triples though, can't we? 15:34:32 This is how DOM Storage affects RDFa: If HTML5 parsers munge the values in @rel and @rev when building the DOM, we're in trouble. If HTML5 parsers preserve case in @rel and @rev when building the DOM, we're in good shape. 15:34:48 yes, and the triples we generate should be all lower-case. 15:34:56 MUST be all lower-case. 15:35:16 Well, now you are mixing up a couple of things. 15:35:28 The triples we generate will be based on the token mappings. 15:35:44 that's true 15:35:47 "next" is a token that maps to a URI, isn't it? 15:35:52 yes 15:36:02 but remember... we're not just matching on next 15:36:09 We're also matching on NeXt and NExt 15:36:11 So we support "NexT", but it's just the same URI. 15:36:18 that is correct. 15:36:49 Right, but the algorithm is simply that when checking for HTML link-types, use case-insensitive matching. 15:36:57 right 15:37:02 Now, if HTML 5 leaves the values alone, then we're done. 15:37:11 but that means that it's not just simply "look it up in our list of mappings" 15:37:22 I don't think it ever was. 15:37:37 But anyway, it's only an extra function call when you are testing. 15:37:38 it's "determine if the term is a special HTML4.01 term, and then lowercase it, and then look it up in our list of mappings" - or something to that effect. 15:37:54 If you like. 15:37:56 :) 15:37:59 so this is all good, but it's the the issue I'm concerned about... 15:38:09 Or just "compare case-insensitively". 15:38:16 I.e., match the HTML specs. 15:38:29 the issue I'm concerned about is if there is an HTML5 processor out there that would take this: rel="conformsTo" and store it in the DOM as this: rel="conformsto" 15:39:05 Yes, now if that *is* the case, then it doesn't affect tokens (or "terms") but it does affect @vocab. 15:39:10 right 15:39:22 and like I said, I don't think that's the case... but I'm concerned about it. 15:39:30 I've never liked @vocab anyway, but I see why other people do. :) 15:39:55 I've always felt that @profile is the big leap forward, and is what people will use more. 15:40:00 I agree 15:40:08 And that is not called into question if HTML 5 munges up @rel values. 15:40:12 but @vocab is useful when you're doing quick one-off snippets. 15:40:16 that all use the same vocab 15:40:17 Sure. 15:40:19 like OGP or Google's 15:40:27 @vocab is good for beginners. 15:40:41 But it occurred to me the other day that we should clarify what this does: 15:40:59
15:41:00 ... 15:41:02
15:41:23 So there may be other shorthands available to us. 15:41:39 And of course, we may not even have to worry, if @rel is untouched. 15:42:17 tinkster has joined #rdfa 15:43:15 mark, @profile value is defined as @href or @src; which also allows for relative URI-s afaik 15:43:22 and I am a bit afraid that would lead to a mess 15:43:38 ie, we may want to specify that @profile values are absolute URI-s 15:43:44 sorry 15:44:08 No need to apologise. It's not decided yet. :) 15:44:09 not absolute URIs but not fragments 15:44:18 or something like that 15:44:19 I'm concerned that, while useful, it complicates implementations and I'm not sure it has a big up-side. 15:44:26 manu, I agree 15:44:40 I'm straining to think of how I'd use that... 15:44:44 it will screw up implementations, actually, because processors can get into an infinite cycle 15:44:46 use an in-page profile... 15:44:47 You guys are too literal. :) 15:45:01 I'm merely saying we might find another way to give people these quick shorthands. 15:45:04 Hard not to be literal when you're dealing with text on IRC :P 15:45:27 oh, so you mean, replace @vocab w/ something else. 15:45:29 ? 15:45:40 No...I mean I'm simply throwing out the notion that there are other mechanisms we could work on. 15:45:47 I'm not trying to define it here. 15:45:50 let us try not to reopen closed issues, gents, we do want to finish this working group in time:-) 15:46:03 You've missed the point Ivan. 15:46:07 ? 15:46:21 no harm in discussing this stuff out of WG, though... 15:46:25 *If* HTML 5 screws up @rel values and affects their case then the *only* thing that is affected is @vocab. 15:46:35 yes 15:46:37 right 15:46:37 If HTML 5 leaves them alone, then nothing changes. 15:46:54 I'm not trying to get rid of @vocab. 15:47:16 But if HTML 5 pulls the rug from under us, I'm saying that it's the only thing that would be affected. 15:47:23 That's it...nothing more. 15:47:57 affected ... so far. HTML5 has the cunning ability to screw people:-( 15:48:04 he he 15:48:26 wouldn't all terms be munged in the case we're worried about... it would affect all terms in the list of mappings. 15:48:28 So, your scenario (on the telecon) of a profile that has all of the FOAF tokens in it is fine. 15:48:44 why is it fine? 15:48:47 yes, I realize that 15:48:52 If HTML 5 munges the attributes then we simply say that tokens are compared case-insensitvely. 15:48:56 it is, because the exact mappint is in the @profile file 15:49:12 what is scrwed is @vocab="FOAFURI" 15:49:26 and then using workplaceHomepage, for example 15:49:27 Yes, and that's what I was explaining to Manu. 15:49:32 Right. 15:49:41 ah right, I see. 15:49:51 I had to go back and read how we process xmlns: and @prefix 15:50:01 we force all keys to lowercase. 15:50:08 in the mapping, that is. 15:50:08 Do we? 15:50:21 I read that in the issue but was surprised. 15:50:21 all xmlns: values are forced to lowercase. 15:50:31 one sec, let me look at the latest spec. 15:50:33 but that is fine, it does not affect the triples, just the way prefixes are used 15:50:37 That's not due to this issue is it? 15:50:47 that is due to xmlns 15:50:51 That's to do with @xmlns processing in HTML 5, I think. 15:51:01 Mappings are defined via @prefix. For backward compatibility, some Host Languages may also permit the definition of mappings via @xmlns. In this case, the value to be mapped is set by the XML namespace prefix, and the value to map is the value of the attribute — a URI. Regardless of how the mapping is declared, the value to be mapped must be converted to lower case, and the URI is not... 15:51:03 ...processed in any way; in particular if it is a relative path it is not resolved against the current base. Authors should not use relative paths as the URI. 15:51:03 Right. But why do we do it for @prefix? 15:51:08 ivan has left #rdfa 15:51:59 Anyway...I think I'm up to speed now. 15:52:11 I forget why we do it for @prefix - perhaps to be orthogonal. 15:52:14 I thought there was some place in the HTML 5 spec that was talking about converting attribute values. 15:52:24 And I couldn't find it...worried me. 15:52:25 :) 15:52:29 in any case, what we have in the spec now is bad. 15:52:31 But sounds like there isn't. 15:52:47 right? 15:52:53 Which part? 15:53:53 that would mean: prefix="conformsTo: http://purl.org/dc/terms/conformsTo" would lowercase "conformsTo", right? 15:54:41 Yes, it would. 15:55:01 which would mean that this wouldn't generate a triple: rel="conformsTo" ? 15:56:02 ah, no, I don't think that's right 15:56:26 we keep the 'term mappings' separate from 'prefix mappings' 15:56:38 Unfortunately, so. :) 15:56:48 I'll be raising that at last call, of course. ;) 15:56:49 @xmlns: and @prefix only affect 'prefix mappings' 15:57:02 but it saved us in this instance, Mark! :) 15:57:11 well, not really. 15:57:25 Not really, because you could do case-insensitive matching on the tokens. 15:57:46 I.e., you could just adopt the HTML 4/5 approach and have done with it. 15:58:35 Interesting that everyone is critical on relative URIs in @rel, but that's exactly what @vocab+@rel is. 15:58:48 s/critical on/critical of/ 15:59:39 But anyway, one approach is to simply adopt the HTML 4/5 approach, and then we're safe, regardless of what the browser does. 15:59:50 We then have to think of a different way of doing @vocab. 16:03:02 I don't think "everyone is critical of relative URIs" 16:03:24 I think "people are critical of relative URIs in certain attributes like @datatype and @property" 16:03:33 people are critical of relative URIs for predicates. 16:03:50 or using relative URIs to specify predicates via @property, @datatype, etc. 16:04:23 that the predicate that you're using is defined in the same document... I think that's what people are critical of 16:05:58 It seems more difficult to 'ban' it than to leave it in, but anyway, the thing is that @vocab is almost (but not quite) a relative URI. 16:06:21 It is a little confusing for people, because it gives us yet another way of creating URIs. 16:07:26 The tricky bit now though is that we have to decide whether to continue with case-sensitive values in @rel... 16:07:38 ...with the risk that some browsers might pull the rug from under us. 16:08:33 Or protect ourselves now from this possibility by making the values into 'token-only' values... 16:08:47 ...and defining token-processing as being case-insensitive. 16:13:22 mind if I share w/ the mailing list? 16:13:32 It'll help them come up to speed. 16:14:04 Sure. 16:15:33 kennyluck has joined #rdfa 16:20:33 He he...just read this in HTML 4.01: 16:20:36 "User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar." 16:20:51 So there was no need to add @version anyway! 16:21:09 We were perfectly entitled to interpret the @rel values without the author's 'permission'. 16:29:09 :) 16:29:23 Just remember that when the TAG rains fire and brimstone down upon us. 16:34:25 manu has left #rdfa 17:39:29 tinkster has joined #rdfa 17:52:21 ShaneM has joined #rdfa 18:38:34 markbirbeck has joined #rdfa 20:09:49 markbirbeck has joined #rdfa