Re: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
On Sat, 9 May 2009, Manu Sporny wrote: For rel-license, the HTML5 spec defines the value to apply to the content and not the page as a whole. This is a recent change to match actual practice and I will be posting about this shortly. Hmm, yes - after re-reading the definitions, they do differ... especially in how the hAudio Microformat uses rel=license. I find the HTML5 one to be very problematic. Microformats rel=license is better, and the RDFa use of rel=license is even better (I can go into the reasoning if those on the list are curious). The definition in HTML5 is just a description of how it's used in practice. It's not what I'd design if I had a choice. However, there's not much point defining something that doesn't match the reality of the situation. For example, in HTML5, how do you express 20 items on a page, each with separate licenses? How do you differentiate a page that has 3 primary topics, each with a separate license? You can't, currently. Can you provide a sample of such a page? In short - what's the purpose of rel=license if a machine can't use it to help the person browsing identify important sections of a page? rel=license as it stands today is useful only (as far as I can tell) for people searching the Web for pages whose main content (e.g. the photo on a Flickr page, the text of a blog post on a blog post's permalink, etc) is licensed under a particular license identified by URI. Afterall, it's only machine readable, isn't it? What's the sense in having rel=license if a machine can't be sure of the section of the page to which it applies? Generally speaking, search engines are pretty competent at distinguishing the page's main content from ancillary content such as style sheets or navigation links. More importantly, if you see this as an issue, why don't you see the semantic difference between rel=alternate[3] in HTML4 and rel=alternate[4] in HTML5 as being an issue? That case is even worse, exactly the same string - entirely different semantics. HTML5's definition, again, matches what actual implementations and author usage is. HTML5 isn't trying to be compatible with HTML4, it's trying to be compatible with legacy content. You would have to ask them. I tend not to argue with implementor feedback. If they tell me they won't do something, I don't tell them to do it. I would expect the primary editor for a web specification to understand the reason that every single one of their implementors refuse to implement a technique that they use elsewhere in their products. I believe I do, but I wouldn't want to put words in their mouth on such controversial topics. I'd love to ask eacho of them why it is perceived as difficult and discuss possible solutions. A public e-mail would be best so that we can discuss on this list, but a private e-mail would be fine as well. So please, if your organization has decided to not resolve prefixes in attribute values, please send me an e-mail. After two weeks, I'll check back in with the mailing list to report on the number of responses I received and a summary of the reasoning (anonymized, of course) for the benefit of this community. Did you receive any responses? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
Julian wrote: You are aware of MNot's Web Linking draft (http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html), and the fact that it seems to enjoy support from the TAG? Julian, you continue to bring this up as if we hadn't already discussed this: there are significant differences of opinion with mnot on whether his interpretation of @rel values is correct in prior HTML versions, and there are a number of folks who disagree (not just us in RDFa), including at least two RECs (RDFa and GRDDL). The point is: if you assume that @rel=foo always means the same thing, then many folks believe you're already violating the HTML spec, which specifically uses @profile to modulate the meaning of @rel, and sometimes via another level of indirection. -Ben
Re: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
Ian Hickson wrote: On Thu, 7 May 2009, Manu Sporny wrote: That's certainly not what the WHATWG blog stated just 20 days ago for rel=license [...] The WHATWG blog is an open platform on which anyone can post, and content is not vetted for correctness. Mark can sometimes make mistakes. Feel free to post a correction. :-) Well, the problem is that I don't know who to correct - you or Mark. It's unclear to me if it's the spec that needs correcting or the blog post? For rel-license, the HTML5 spec defines the value to apply to the content and not the page as a whole. This is a recent change to match actual practice and I will be posting about this shortly. Hmm, yes - after re-reading the definitions, they do differ... especially in how the hAudio Microformat uses rel=license. I find the HTML5 one to be very problematic. Microformats rel=license is better, and the RDFa use of rel=license is even better (I can go into the reasoning if those on the list are curious). For example, in HTML5, how do you express 20 items on a page, each with separate licenses? How do you differentiate a page that has 3 primary topics, each with a separate license? In short - what's the purpose of rel=license if a machine can't use it to help the person browsing identify important sections of a page? Afterall, it's only machine readable, isn't it? What's the sense in having rel=license if a machine can't be sure of the section of the page to which it applies? Surely this is what namespaces were intended for. Uhh, what sort of namespaces are we talking about here? xmlns-style, namespaces? The idea of XML Namespaces was to allow people to extend vocabularies with a new features without clashing with older features by putting the new names in new namespaces. It seems odd that RDFa, a W3C technology for an XML vocabulary, didn't use namespaces to do it. As you are aware, the RDF in XHTML 1.1 Task Force was created to figure out a way to express RDF via XHTML. The standard mechanism for extending XHTML is XHTML Modularization[1]. From the XHTML modularization spec: This modularization provides a means for subsetting and extending XHTML... this specification is intended for use by language designers as they construct new XHTML Family Markup Languages. We used the standard mechanism, specifically designed to extend XHTML vocabularies, approved by the XHTML working group, the W3C TAG and a number of other W3C and public web groups, to extend the language. Had we been tasked with expressing RDF in XML, we would have called it RDF/XML[2]... :) For example, the way that n:next and next can end up being equivalent in RDFa processors despite being different per HTML rules (assuming an n namespace is appropriately declared). If they end up being equivalent in RDFa, the RDFa author did so explicitly when declaring the 'n' prefix to the default prefix mapping and we should not second-guess the authors intentions. My only point is that it is not compatible with HTML4 and HTML5, because they end up with different results in the same situation (one can treat two different values as the same, while the other can treat two different values as different). It is only not compatible with HTML5 if this community chooses for it to not be compatible with HTML5. Do you agree or disagree that we shouldn't second guess the authors intentions if they go out of their way to declare a mapping for 'n'? I don't think that's a relevant question. My point is that it is possible in RDFa to put two strings that have different semantics in HTML4 and yet have them have the same semantics in RDFa. This means RDFa is not compatible with HTML4. Of course it's relevant - the whole reason there are two strings with the same semantics, in your rather contrived example, is because the author went out of their way to make the statement. This doesn't happen by accident - the web page author intended it to happen. More importantly - you've just made the same statement twice in RDFa and once in HTML4. I can't think of a single technically significant negative repercussion for generating a duplicate triple in a corner case. Why does one duplicated triple in a contrived example mean that the entirety of RDFa isn't compatible with HTML4? More importantly, if you see this as an issue, why don't you see the semantic difference between rel=alternate[3] in HTML4 and rel=alternate[4] in HTML5 as being an issue? That case is even worse, exactly the same string - entirely different semantics. If HTML4 validation is a concern, there's even a preliminary HTML4+RDFa DTD that is available: http://www.w3.org/MarkUp/DTD/html4-rdfa-1.dtd I do get your point - but why should we be concerned about it? Browser vendors would not accept having to resolve prefixes in attribute values as part of processing link relations. Why not? You would have to ask them. I tend not to argue with implementor feedback. If they tell me
Re: [whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
On Thu, 7 May 2009, Manu Sporny wrote: That's certainly not what the WHATWG blog stated just 20 days ago for rel=license [...] The WHATWG blog is an open platform on which anyone can post, and content is not vetted for correctness. Mark can sometimes make mistakes. Feel free to post a correction. :-) and the spec doesn't seem to clearly outline the difference in definition either (at least, that's not my reading of the spec): http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-license http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#link-type-tag Actually I just looked at the rel-tag faq and found that it disagrees with what Tantek had told me, so (assuming the faq is normative or that the rel-tag spec does mention this somewhere that I didn't find) the specs do match here. For rel-license, the HTML5 spec defines the value to apply to the content and not the page as a whole. This is a recent change to match actual practice and I will be posting about this shortly. The RDFa specification is very confusing to me (e.g. I don't understand how the normative processing model is separate from the section RDFa Processing in detail), so I may be misinterpreting things, but as far as I can tell: html xmlns=http://www.w3.org/1999/xhtml; head base href=http://example.com// link about=http://example.net/; rel=dc.author href=http://a.example.org// ... ...will result in the following triple: http://example.net/ http://example.com/dc.author http://a.example.org/ . Two corrections: The first is that an RDFa processor would not generate this triple. My apologies, I misinterpreted 5.4.4. Use of CURIEs in Specific Attributes to mean that rel= was a relative-uri-or-curie attribute. (5.4.4. Use of CURIEs in Specific Attributes says it's link-type-or-curie, but 5.4.3. General Use of CURIEs in Attributes doesn't list that as a possibility and at the end says that rel= is an exception only insofar as it supports specific link types as well, which I interpreted differently.) For example, it would be somewhat presumptious of RDFa to prevent any future version of HTML from being able to use the word resource as an attribute name. What if we want to extend the forms features to have an XForms datatype compatibility layer; why should we not be able to use the datatype and typeof attributes? As long as their legacy nature was preserved, and those uses didn't create ambiguity in RDFa processors and semantic equivalence was ensured, I don't see why they shouldn't be re-used. Ah, ok. If such attributes are re-used, I suppose that it should be possible to make sure that it is possible to re-use them in a way that doesn't conflict with RDFa (e.g. by triggering the non-curie-non-uri behaviour for property= or by having authors who want RDFa compatibility use xmlns:http=http: declarations or some such). Noted. Surely this is what namespaces were intended for. Uhh, what sort of namespaces are we talking about here? xmlns-style, namespaces? The idea of XML Namespaces was to allow people to extend vocabularies with a new features without clashing with older features by putting the new names in new namespaces. It seems odd that RDFa, a W3C technology for an XML vocabulary, didn't use namespaces to do it. For example, the way that n:next and next can end up being equivalent in RDFa processors despite being different per HTML rules (assuming an n namespace is appropriately declared). If they end up being equivalent in RDFa, the RDFa author did so explicitly when declaring the 'n' prefix to the default prefix mapping and we should not second-guess the authors intentions. My only point is that it is not compatible with HTML4 and HTML5, because they end up with different results in the same situation (one can treat two different values as the same, while the other can treat two different values as different). It is only not compatible with HTML5 if this community chooses for it to not be compatible with HTML5. Do you agree or disagree that we shouldn't second guess the authors intentions if they go out of their way to declare a mapping for 'n'? I don't think that's a relevant question. My point is that it is possible in RDFa to put two strings that have different semantics in HTML4 and yet have them have the same semantics in RDFa. This means RDFa is not compatible with HTML4. Another example would be: html xmlns=http://www.w3.org/1999/xhtml; head about= link rel=stylesheet alternate next href=... ... ...which in RDFa would cause the following triples to be created: http://www.w3.org/1999/xhtml/vocab#stylesheet ... . http://www.w3.org/1999/xhtml/vocab#alternate ... . http://www.w3.org/1999/xhtml/vocab#next ... . ...but according to
[whatwg] Micro-data/Microformats/RDFa Interoperability Requirement
bcc: Public RDFa Task Force mailing list (but not speaking as a member) Thinking out loud... It seems as though there is potential here, based on the recent IRC conversations about the topic[1] and the use cases[2] posted by Ian, that WHATWG's use cases/requirements, and therefore solution, could diverge from both the Microformats community as well as the RDFa community use cases/requirements/solution. There should be a requirement, as Microformats and XHTML1.1+RDFa have required, that a potential solution to this issue should be compatible with both the Microformats and RDFa approaches. This would mean, at a high-level: - Not creating ambiguous cases for parser writers. - Not triggering output in a Microformats/RDFa parser as a side-effect of WHATWG micro-data markup. - Not creating an environment where WHATWG micro-data markup breaks or eliminates Microformats/RDFa markup. I think these are implied since HTML5 has gone to great lengths to provide backward compatibility. However, since I'm not clear on the details of how this community operates, I thought it better to be explicit about the requirement. -- manu [1]http://krijnhoetmer.nl/irc-logs/whatwg/20090430#l-693 [2]http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019374.html -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: A Collaborative Distribution Model for Music http://blog.digitalbazaar.com/2009/04/04/collaborative-music-model/
