It’s just data
Shelley Powers: One unfortunate consequence of switching DOCTYPEs is that when I do use embedded SVG, the page won’t validate. However, this won’t impact on the user agents and their ability to process the SVG correctly, so I’ll just have to live with the invalidation errors. That’s the joy of DOCTYPEs.
We either need a DOCTYPE that supports both RDFa and SVG and that a validator recognizes, or a validator that doesn’t rely on DOCTYPE that supports RDFa.
Or even better, just stop using <!DOCTYPE> entirely. It is part of the problem, not part of the solution.
Posted by Tim atThat’s what I meant by “a validator that doesn’t rely on DOCTYPE”.
Unfortunately, some sort of DOCTYPE is required in order to avoid triggering quirks mode in browsers, that’s why HTML5 specifies:
<!DOCTYPE html>
Short. Sweet. No extra bells or whistles. The only downside is that you are limited to the “builtin” character references. For example, no , no —.
Try a two stage process.
Validate with nvdl, using xhtml and svg, then, when ready for the web,
and identity transform, output method='html', specify your doctype
and mime type.... and encoding; Job done.
<aside> No claim for credit. Suffering similar issues with a CSS demo. DC suggested
this as a practical workaround</aside>
DaveP
Posted by Dave Pawson atValidate with nvdl, using xhtml and svg
Is there a howto someplace? Is there a schema for RDFa?
identity transform, output method='html'
Why?
Posted by Sam Ruby atFrankly, I’m surprised that more bloggers don’t have the cojones to allow comments to make use of straightforward markup innovations like the article element.
Posted by Mark at<aside>or even the aside element</aside>
Posted by Mark atCan articles nest in html5?
Posted by Sam Ruby atNow, aside I could do. I would just need to figure out what css would be appropriate for such a thing.
Note: Dave apparently literally typed the characters <aside>, and did not make use of the ample preview facilities made available by this weblog.
Since the topic seem to have diverged slightly, if we’re going to have “markup innovations”, I guess I’m not sure I like the use of “article” since it seems like its usage goes beyond things which would normally be termed “articles”. Why not the more generic Atom-esque “entry” or would that cause confusion? Might make the nested situation seem slightly more rational?
Posted by Bob Aman atAre we talking about text/html <!DOCTYPE>s or XML <!DOCTYPE>s?
Posted by Ian Hickson atIan: that would depend on the user agent that requests it.
Currently, in order to render the SVG on Firefox, Safari, Opera, or Chrome, the content must be served as application/xhtml+xml.
Currently, in order to render pretty much anything on IE, the content must be served as text/html.
Frankly, I’m surprised that more bloggers don’t have the cojones to allow comments to make use of straightforward markup innovations like the article element.
I, for one, won’t.
I want user-entered content, that’s valid today, to be valid five years from now. Without a stable Spec, I have no reason to believe that will be the case.
Call me a markup stick-in-the-mud...
Posted by Jacques Distler atWe either need——
I think that’s a false dichotomy.
Henri: suggestions?
I suggest not using RDFa.
RDFa has been designed for XML without paying proper attention to text/html integration. I think CURIEs are bad for the platform, because they have all the problems of qNames in content, which is a known anti-pattern. There’s a TAG finding explaining some of the issues. The TAG finding isn’t comprehensive; there are further issues in a dynamic DOM context. (The usual refutation is saying something along the lines of “CURIEs are not qnames”. That’s a bad refutation, because CURIEs share the bad characteristics of qnames in content.)
Moreover, RDFa hoists the RDF tax onto those parts of the HTML community who don’t need RDF-interop. If an RDFa-based vocabulary became the de facto standard for expressing an interesting thing, non-RDF HTML authors would need to deal with URIs as identifiers, triples, CURIE prefix-based indirection, etc. The non-RDF part of the community wouldn’t have the option of operating with simple tokens (without breaking the processing model). (Compare with the discussion way back when some people wanted to make Atom RDF-based and the other part of the community didn’t want the complexity.)
Instead, I suggest using ideas from the Atom rel registry, eRDF (see this Warnocked email), OWL (sameAs) and GRDDL and developing a text/html-friendly (particularly adhering to the DOM Consistency Design Principle) way of putting microformat-like data in HTML in such a way that it can be processed using simple token comparison and trees when the consumer doesn’t need URIs and graphs but can be mapped to RDF when desired. This way, the RDF tax would be borne by those who wish to map the data to RDF.
That is: Mapping data expressed in text/html onto RDF graphs when the consumer wants RDF is totally cool. I just think that those producers and consumers who don’t have RDF-based systems shouldn’t have to pay a complexity tax because others want interop with a more complex model.
RDFa has been designed for XML
As luck would have it, Shelley’s pages are well-formed XHTML, and served as application/xhtml+xml to user agents that support that MIME type. What would be helpful is if there were to be a XHTML validator that supports SVG and RDFa in the same page.
“We either need a DOCTYPE that supports both RDFa”
Why support RDFa at all?
Posted by Bill de hÓra atSam: we’re working on an XML schema for RDFa. That step required XHTML 1.1 Modularization to be a REC, and that just happened recently. Absolutely agreed that schema-based validation would be preferred.
Henri: it’s hard to keep track of all the places where you post the same old arguments while refusing to take into account the responses you’ve already seen multiple times on the HTML5 list. You’re arguing about non-XML HTML before we’ve even made a recommendation for RDFa in that context. It’s a bit hard to respond to criticism of things we haven’t even said :)
In the XML world, qnames-in-content is something we all have to live with already in XSLT, so that ship sailed a long time ago. We’ll get to the text/html issues, but it takes a little bit longer because the RDFa task force uses consensus to make its decisions. We’re actively discussing it, as you can see on our public mailing lists, wiki, and blog [link].
Posted by Ben Adida at(Not an official W3C position, just food for thoughts)
I would prefer a solution where people can use RDFa without having to rely on the doctype at all. So a conformance checker would check that the document is indeed conformant xhtml, html, etc (ignoring the RDFa attributes) AND would verify that the RDFa into it is indeed good.
People will right away jump on “but why not my vocabulary could be added to the validator too”. The rationale to include a vocabulary inside the validator would be to have the backup of a W3C spec.
This suggestion is practical because we all know that whatever we do, people will use RDFa valid or not. It will happen. The cat is out of the box. All RDFa parsers already know how to handle html and does not require the document to be xhtml.
Posted by karl dubost, w3c atYou’re arguing about non-XML HTML before we’ve even made a recommendation for RDFa in that context.
That there’s a need to make a separate recommendation for that context shows that RDFa hasn’t been designed according to the HTML Design Principles, which in itself is a problem that can be criticized already.
In the XML world, qnames-in-content is something we all have to live with already in XSLT, so that ship sailed a long time ago.
The cat is out of the box.
XSLT is different, because XSLT generally goes directly from an XML parser to an XSLT compiler/interpreter, so the issues are mitigated. In any case, that XSLT has them is no reason to introduce them into other languages.
It is interesting that the pro-RDFa reasons are of the type “live with” and “cat is out of the box”.
Posted by Henri Sivonen atHenri,
… “the cat is out the box” was not an argument pro-RDFa. Just a fact.
Posted by karl dubost, w3c atI’d note that Dave and Karl’s comments are two views of the same idea, and I would tend to agree with it. nvdl clearly seems like the right solution to check xml-based documents mixing markup from different namespaces.
DTDs are somewhat convenient for validation.A DTD-based validator doesn’t have to be aware of XHTML+SVG+RDFa, you just have to feed it a document that refers to the proper DTD. You don’t even need an “XHTML validator that supports SVG and RDFa in the same page” - just a DTD-aware validator and the right DTD. The issue is that DTDs aren’t so easy to build - at least for most of us puny humans - or maintain.
Posted by olivier Thereaux atFWIW, there is an early version of the XML Schema implementation of XHTML+RDFa available. You can find it at [link] - feel free to use this to validate your content now if you like. Just keep in mind that it might change a little along the way to becoming a formal W3C Recommendation.
Posted by Shane McCarron atHenri: no, it is not reasonable to criticize RDFa based on HTML5’s design principles, which were written (at least in W3C land) after RDFa was chartered, and which are not the result of a consensus process. The world does not revolve around HTML5.
Posted by Ben Adida atAgain - Why support RDFa at all?
Posted by Bill de hÓra atI’m all for eliminating DOCTYPEs, but I’m not feeling particularly quirky, as Sam mentioned.
Bill: “Why support RDFa at all?”
Because...it’s a released specification with a purpose that matches a need and that’s relatively easy to use? Alternatively: because I want to use it?
Karl and Dave, I like your idea(s). However, the Semantic Radar at least checks for DOCTYPE, and if the RDFa DOCTYPE isn’t used, doesn’t pick up on the RDFa annotation. I had expected the profile statement would be sufficient, but no, by itself, it doesn’t trigger the Semantic Radar RDFa detector.
Henri, if there’s an “RDF tax” for RDFa, it’s fast approaching a Libertarian tax. Drupal 7 plans to add the functionality to generate the RDFa for everything but in-post annotation, and other tools then read this data for various applications. Few developers have to sully their dainty little fingers dealing with RDF, directly. Best of all, there are no boundaries on the data, no built-in limitations, no committees that have to say yay or nay on new vocabularies. We don’t have to have endless rounds of negotation for the addition of...oh...something like SVG.
Ben: “The world does not revolve around HTML5.”
Goodness, Ben, you’re such a rebel. Next thing we know, you’ll be burning your browser.
Posted by Shelley atkarlw3c: @olivier_t_w3c Interesting post from sam Ruby about usage of RDFa and validation - [link]...
Excerpt from Twitter / karlw3c atSam Ruby: RDFaification Henri: it’s hard to keep track of all the places where you post the same old arguments while refusing to take into account the responses you’ve already seen multiple times on the HTML5 list.Henri passe-t-il le test de Turing...
Excerpt from La Tortue Cynique / The Cynical Turtle atHenri: it’s hard to keep track of all the places where you post the same old arguments while refusing to take into account the responses you’ve already seen multiple times on the HTML5 list. Henri passe-t-il le test de Turing ?...
Excerpt from Public marks from user night.kame atShelley: I think what Henri is saying is that RDFa was designed for XML, and as you and I both know, there’s only a few of us that are using XML on the web, everyone else is using text/html.
Posted by Dean Edridge atDean: while that’s a true statement, but the question is why would somebody who has implemented an XHTML validator willfully and intentionally chose not to support RDFa?
Posted by Sam Ruby atno, it is not reasonable to criticize RDFa based on HTML5’s design principles, which were written (at least in W3C land) after RDFa was chartered, and which are not the result of a consensus process.
Well, part of the problem is appealing to the timeline of things getting written down in the W3C land. The technical constraints of text/html regarding namespaces have been well-known long before RDFa was chartered.
but the question is why would somebody who has implemented an XHTML validator willfully and intentionally chose not to support RDFa?
The generic facet of Validator.nu supports any RELAX NG schema (using the XSD, DTD compat or HTML5 datatype libraries) and any XPath 1.0-based Schematron 1.5 schema.
The presets and the HTML5 facet support things that at least two of Opera, Safari/Chrome, Firefox and IE support except for HTML5 features which are supported ahead of browser implementation due my special interest in tracking HTML5. (Yes, now that Gecko and WebKit have explicitly rejected xml:id, it follows that I should pull xml:id support. And yeah, by this definition, I should probably pull ruby support from the XHTML 1.0 presets.)
Henri: forgive me, but you did not answer my question.
What support for RDFa would you expect from browsers that is lacking? To my reading, all that is required is that this data is placed correctly in a DOM.
In the feedvalidator, if the spec says one thing and implementations do another, I produce a warning not an error.
Posted by Sam Ruby atSaying that browsers don’t need to do anything but place the data in the DOM is a trick for dodging the issue that the design of RDFa doesn’t take text/html parsing behavior into account properly.
But suppose browsers don’t have any conformance requirements and are only expected to place the data into the DOM like any other data. Why would people care even about the data getting into the DOM if they had no intention of examining it in any way inside a browser? And when one does examine it inside a browser, one needs different code paths for text/html and application/xhtml+xml, which, in my opinion, means that RDFa is broken as designed, considering that it was designed at a time when regardless of when HTML Design Principles were written everyone who writes Web-related specs should have known that xmlns:foo="..." gets different DOM treatment in text/html and application/xhtml+xml. (It’s pretty clear that RDFa proponents want to put it into “XHTML” served as text/html as well.)
But to answer your question about why I don’t consider browsers to support RDFa: Browsers don’t have default behavior for RDFa markup that the user could perceive in the absence of scripting without extensions and browsers don’t have RDFa-specific JavaScript APIs, either.
Posted by Henri Sivonen atWhat is the default behavior for custom data attributes? How is that different?
Posted by Sam Ruby atBut suppose browsers don’t have any conformance requirements and are only expected to place the data into the DOM like any other data. Why would people care even about the data getting into the DOM if they had no intention of examining it in any way inside a browser?
The answer to that is super easy and this comment from Henri might be showing one of the issues we are dealing with. Web pages are not only made for browsers. They can be part of the Web and visible through other UIs. Data contained in these pages can have a live outside of the browser. Browsers are just one class of products.
why I don’t consider browsers to support RDFa
:) People don’t ask browsers to support RDFa :) but that RDFa be usable in the markup.
Posted by karl dubost, w3c atWhat is the default behavior for custom data attributes? How is that different?
Custom data attributes come with a JS API. However, even if they didn’t, custom data attributes are available in the same way in DOM parsed from text/html and application/xhtml+xml, so they aren’t bad for the platform in the sense that they don’t violate the DOM Consistency Design Principle. (So I guess I should present the two-browser criterion as an exclusion criterion and not as inclusion criterion.)
The answer to that is super easy and this comment from Henri might be showing one of the issues we are dealing with. Web pages are not only made for browsers.
Sure there are other page consumers, but what was under discussion was DOM exposure in browsers.
If you consider non-browser applications using a conforming HTML parser for text/html and an XML parser for application/xhtml+xml for XML, you run into the problem of needing different code for examining the document tree in the text/html and application/xhtml+xml cases. So violating the DOM Consistency Design Principle is bad for non-browser apps, too.
:) People don’t ask browsers to support RDFa :)
I don’t agree. For example, Mozilla Ubiquity was mentioned in the WHATWG RDFa thread as if it should have RDFa support.
Posted by Henri Sivonen atHow is RDFa going to help sites like Wikipedia?: ←Older revision Revision as of 20:25, 14 February 2009 Line 34: Line 34: == How is RDFa going to help sites like Wikipedia? == == How is RDFa going to help sites like Wikipedia? == How is RDFa going...
Excerpt from RDFaWiki - Recent changes [en] atMoved page because undelete is failing ←Older revision Revision as of 03:32, 17 February 2009 Line 1: Line 1: - # REDIRECT [[ Developer - faq ]] + = Search Questions = + + == Would a search system based on RDFa give better...
Excerpt from RDFaWiki - Recent changes [en] atQNames have been identified as a known anti-pattern, does RDFa revive QName use?: ←Older revision Revision as of 16:15, 17 February 2009 (2 intermediate revisions not shown.) Line 70: Line 70: QNames have been...
Excerpt from RDFaWiki - Recent changes [en] atQNames have been identified as a known anti-pattern, does RDFa revive QName use?: ←Older revision Revision as of 16:15, 17 February 2009 (2 intermediate revisions not shown.) Line 70: Line 70: QNames have been...
Excerpt from RDFaWiki - Recent changes [en] atSam Ruby: RDFaification Or even better, just stop using <!DOCTYPE> entirely. It is part of the problem, not part of the solution.Posted by Tim at16:55That’s what I meant by “a validator that doesn’t rely on DOCTYPE”.Unf... vantguarde RDFa...
Excerpt from vantguarde / RDFa (49) at