Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Shelley Powers ha scritto: The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes *is there another data model already as vetted, documented, implemented that would better solve the problem*. RDF in a separate XML-syntax file, perhaps. Just because that use case raised a privacy concern on informations to keep private anyway, and that's not a problem solvable at the document level with metadata; instead, keeping relevant metadata in a separate file would help a better access control. Also, a separate file would have the relevant informations ready for use, while embedding them with other content would force a load and parsing of the other content in search of relevant metadata (possible, of course, and not much of a problem, but not as clean and efficient). Moreover, it should be verified whether social-network service providers agree with such a requirement: I might avail of a compliant implementation to easily migrate from one service to another and leave the former, in which case why should a company open its inner infrastructure and database and invest resources for the benefit of a competitor accessing its data and consuming its bandwidth to catch its customers? (this is not the same interoperability issue for mail clients supporting different address book formats, minor vendors had to do that to improve their businness - and they didn't need to access a competitor's infrastructure). Perhaps, that might work if personal infos and relationships were handled by an external service on the same lines of an OpenID service allowing an automated identification by other services; but this would reduce social networks to be a kind of front-end for such a centralized management (and service providers might not like that). Also, in this case anonimity should be ensured (for instance, I might have met you in two different networks, but knew your identity in only one of them, and you might wish that no one knew you're the person behind the other nickname; this is possible taking different informations in different databases and with different access rights, and should be replicable when merging such infos -- on the other hand, if you knew my identity, you should be allowed to fill in the blanks somehow). Shelley Powers ha scritto: Anne van Kesteren wrote: On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers shell...@burningbird.net wrote: And regardless of the fact that I jumped to conclusions about WhatWG membership, I do not believe I was inaccurate with the earlier part of this email. Sam started a new thread in the discussion about the issues of namespace and how, perhaps we could find a way to work the issues through with RDFa. My god, I use RDFa in my pages, and they load fine with any browser, including IE. I have to believe its incorporation into HTML5 is not the daunting effort that others make it seem to be.' You ask us to take you seriously and consider your feedback, it would be nice if you took what e.g. Henri wrote seriously as well. Integrating a new feature in HTML is not a simple task, even if the new feature loads and renders fine in Internet Explorer. Take you guys seriously...OK, yeah. I don't doubt that the work will be challenging, or problematical. I'm not denying Henri's claim. And I didn't claim to be the one who would necessarily come up with the solutions, either, but that I would help in those instances that I could. It seems that you'd expect RDFa to be specced out before solving related problems (so to push their solution). I don't think that's the right path to follow, instead known issues must be solved before making a decision, so that the specification can tell exactly what developers must implement, eventually pointing out (after/while implementing) newer (hopefully minor) issues to be solved by refining the spec (which is a different task than specifying something known to be, let's say, buggy or uncertain). Everything, as always, IMHO WBR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Blu American Express: gratuita a vita! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8613d=4-2
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Shelley Powers ha scritto: The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes *is there another data model already as vetted, documented, implemented that would better solve the problem*. RDF in a separate XML-syntax file, perhaps. Just because that use case raised a privacy concern on informations to keep private anyway, and that's not a problem solvable at the document level with metadata; instead, keeping relevant metadata in a separate file would help a better access control. Also, a separate file would have the relevant informations ready for use, while embedding them with other content would force a load and parsing of the other content in search of relevant metadata (possible, of course, and not much of a problem, but not as clean and efficient). Moreover, it should be verified whether social-network service providers agree with such a requirement: I might avail of a compliant implementation to easily migrate from one service to another and leave the former, in which case why should a company open its inner infrastructure and database and invest resources for the benefit of a competitor accessing its data and consuming its bandwidth to catch its customers? (this is not the same interoperability issue for mail clients supporting different address book formats, minor vendors had to do that to improve their businness - and they didn't need to access a competitor's infrastructure). Perhaps, that might work if personal infos and relationships were handled by an external service on the same lines of an OpenID service allowing an automated identification by other services; but this would reduce social networks to be a kind of front-end for such a centralized management (and service providers might not like that). Also, in this case anonimity should be ensured (for instance, I might have met you in two different networks, but knew your identity in only one of them, and you might wish that no one knew you're the person behind the other nickname; this is possible taking different informations in different databases and with different access rights, and should be replicable when merging such infos -- on the other hand, if you knew my identity, you should be allowed to fill in the blanks somehow). Shelley Powers ha scritto: Anne van Kesteren wrote: On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers shell...@burningbird.net wrote: And regardless of the fact that I jumped to conclusions about WhatWG membership, I do not believe I was inaccurate with the earlier part of this email. Sam started a new thread in the discussion about the issues of namespace and how, perhaps we could find a way to work the issues through with RDFa. My god, I use RDFa in my pages, and they load fine with any browser, including IE. I have to believe its incorporation into HTML5 is not the daunting effort that others make it seem to be.' You ask us to take you seriously and consider your feedback, it would be nice if you took what e.g. Henri wrote seriously as well. Integrating a new feature in HTML is not a simple task, even if the new feature loads and renders fine in Internet Explorer. Take you guys seriously...OK, yeah. I don't doubt that the work will be challenging, or problematical. I'm not denying Henri's claim. And I didn't claim to be the one who would necessarily come up with the solutions, either, but that I would help in those instances that I could. It seems that you'd expect RDFa to be specced out before solving related problems (so to push their solution). I don't think that's the right path to follow, instead known issues must be solved before making a decision, so that the specification can tell exactly what developers must implement, eventually pointing out (after/while implementing) newer (hopefully minor) issues to be solved by refining the spec (which is a different task than specifying something known to be, let's say, buggy or uncertain). Everything, as always, IMHO WBR, Alex -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Blu American Express: gratuita a vita! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8614d=4-2
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Calogero Alex Baldacchino wrote: It seems that you'd expect RDFa to be specced out before solving related problems (so to push their solution). I don't think that's the right path to follow, instead known issues must be solved before making a decision, so that the specification can tell exactly what developers must implement I think that an help in defining of the requirements around structured data, RDFa, metadata copypaste, semantic links [1],etc could came from the W3C document Use Cases and Requirements for Ontology and API for Media Object 1.0 [2] Take the requirements listed from r01 to r13 and replace the term media objects with structured/linked data. [1] http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html [2] http://www.w3.org/TR/2009/WD-media-annot-reqs-20090119/#req-r01 -- Giovanni Gentili
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Dan Brickley wrote: On 18/1/09 20:07, Henri Sivonen wrote: On Jan 18, 2009, at 20:48, Dan Brickley wrote: On 18/1/09 19:34, Henri Sivonen wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? I don't believe the RDFa TF are in a position to singlehandedly rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/. What they presumably could do is propose new work items within W3C, which I'd guess would be more likely to be accepted if it had the active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have something more to add. Do you have an alternative design in mind, for expressing the namespace mappings? The simplest thing is not to have mappings but to put the corresponding absolute URI wherever RDFa uses a CURIE. So this would be a kind of interoperability profile of RDFa, where certain features approved of by REC-rdfa-syntax-20081014 wouldn't be used in some hypothetical HTML5 RDFa. If people can control their urge to use namespace abbreviations, and stick to URIs directly, would this make your DOM-oriented concerns go away? Took five minutes to make this change in my template. Ran through validator.nu. Results: Doesn't like the content-type. Didn't like profile on head. Having to remove the profile attribute in my head element limits usability, but I'm not going to throw myself on the sword for this one. Doesn't like property, doesn't like about. These are the RDFa attributes I'm using. The RDF extractor doesn't care that I used the URIs directly. Didn't seem to mind SVG, but a value of none is a valid value for preserveAspectRatio. Shelley cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Eduard Pascual wrote: On Sun, Jan 18, 2009 at 3:56 PM, Anne van Kesteren ann...@opera.com wrote: On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers shell...@burningbird.net wrote: My apologies for not responding sooner to this thread. You see, one of the WhatWG working group members thought it would be fun to add a comment to my Stop Justifying RDF and RDFa web post, which caused the page to break. I am using XHTML at my site, because I want to incorporate inline SVG, in addition to RDFa. An unfortunate consequence of XHTML is its less than forgiving nature regarding playful pranks such as this. I'm assuming the WhatWG member thought the act was clever. It was, indeed. Three people emailed me to let me know the post was breaking while loading the page in a browser, and I made sure to note that such breakage was courtesy of a WhatWG member, who decided that perhaps I should just shut up, here and at my site, about the Important Work people(?) here are doing. Of course, the person only highlighted why it is so important that something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML is hard to support when you're allowing comments and external input. Typically my filters will catch the accidental input of crappy markup, but not the intentional. Not yet. I'm not an exerpt at markup, but I know more than the average person. And the average person most likely doesn't have my commitment, either. http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by the way seems to be on your side in this debate) simply forgot to escape self-closed / and then WordPress somehow messed up in an attempt to fix it. I don't think anyone tries to make you shut up. Ouch! Thanks Anne for the screenshot, otherwise I wouldn't have known that it was my comment the one causing the issue. My apologies Shelley for that incident. I assure you that it was not intentional: it was a quite long post, I used some markup with the intention of making it more readable (like italizing the quotes), and by the end I messed things up. Thanks to the preview page I noticed some issues, like that I had to escape the sarcasm.../sarcasm for it to display (I'm too used to BBCode, which leaves unrecognized markup as is), but I didn't catch the self-closed / one (nor the preview page did: it showed up without issues). Eduard, no worries. Your comment just demonstrated that a secondary preview after editing is needed to self-catch these types of errors. Sorry for the misunderstanding. That and Anne's image, and trying to wade through the markup and figure out what was going on, because this error should have been caught, put me in an irritated mood. Especially since I have had people deliberately trip up my comments every time I write about XHTML et al (ie the Philipe Anne mentions). But no worries, and I shouldn't have made such a jump in assumption. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Ian Hickson wrote: On Sun, 18 Jan 2009, Shelley Powers wrote: The more use cases there are, the better informed the results will be. The point isn't to provide use cases. The point is to highlight a serious problem with this working group--there is a mindset of what the future of HTML will look like, and the holders of the mindset brook no challenge, tolerate no disagreement, and continually move to quash any possibility of asserting perhaps even the faintest difference of opinion. I'm certainly sad that this is the impression I have given. I'd like to clarify for everyone's sake that this mailing list is definitely open to any proposals, any opinions, any disagreement. The only thing I ask is that people use rational debate, back up their opinions with logical arguments, present research to justify their claims, and derive proposals from user needs. I've been especially critical of you, which isn't fair. At the same time, as you have said yourself, you are a benevolent dictator, which seems to me to not be the best strategy for an inclusive HTML for the future. I know I'm not comfortable with the concept. But I'm also late to this group, and shouldn't disrupt if the strategy works. Regardless, I got the point in the comment. That, combined with this email from Ian, tells us that it doesn't matter how our arguments run, the logic of our debate, the rightness of our cause--he is the final arbiter, and he does not want RDFa. For the record, I am as open to us including a feature like RDFa as I am to us including a feature like MathML, SVG, or indeed anything else. While I may present a devil's advocate position to stimulate critical consideration of proposals, this does not mean that my mind is made up. If my mind was made up, I wouldn't be asking for use cases, and I wouldn't be planning to investigate the issue further in April. There is a fine difference between being the devil's advocate, and the devil's front door made of thick oak, with heavy brass fittings. How does one know if one has provided a use case in a format that is more likely to meet a successful outcome, than not. Is the criteria documented somewhere? It's difficult to provide use cases with the twenty questions approach. What are the criteria by which a possible solution to a problem is judged? Is there a consistent set of questions asked? Tests made? A certain number of implementations? Again, is this documented somewhere? I am not paid by Google, or Mozilla, or IBM to continue throwing away my time, arguing for naught. It may be worth pointing out that, many of our most active participants are volunteers, not paid by anyone to participate. Indeed I myself spent many years contributing to the standards community while unemployed or while a student. I am sorry you feel that you need to be compensated for your participation in the standards community, and wish you the best of luck in finding a suitable employer. The point I was trying to make, and forgive me if the my writing was too subtle, is that it's not the fact that the work will time, but whether the time will be well spent. Operating in the dark and tossing use cases in hopes they stick against the wall, without understanding criteria is not a particularly good use of time. However, having specific tasks that meet a given goal, and knowing that the goal is stable, and not a moving target, goes a long way to ensuring that the time spent has value. Knowing that one can, with diligence, ensure that the best result occurs is a good use of time. Spitting into the wind, at the whim and whimsy of a benevolent dictator, is not a good use of time. As far as Google goes, we have no corporate opinion either way on the topic of RDFa in HTML5. We do, however, encourage the continued practice of basing decisions on data rather than hopes. Bully for Google. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Jim Jewett wrote: (But existing W3C standard probably isn't strong enough.) s/probably/certainly/ -Boris P.S. For anyone who cares, I suggest reading http://dbaron.org/log/2006-08#e20060818a for my reasons for saying the above.
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 18, 2009, at 8:43 AM, Shelley Powers wrote: Take you guys seriously...OK, yeah. I don't doubt that the work will be challenging, or problematical. I'm not denying Henri's claim. And I didn't claim to be the one who would necessarily come up with the solutions, either, but that I would help in those instances that I could. What I did express in the later emails, is what others have expressed who have asked about RDFa in HTML5: are we wasting our time even trying? That it seems like a decision has already been made, and we're spinning our wheels even attempting to find solutions. There's a difference between not being willing to negotiate, compromise, work the problem, and just spitting into the wind for no good. Based on past experience, I would say that you are not wasting your time. Evidence-based arguments, explication of use cases, solutions to technical problems, persuading third parties, and getting implementation traction (for example in popular JavaScript libraries, major browser engines, popular authoring/publishing software) will all affect how a feature is seen. As past examples, allowing XML-like self-closing tag syntax for void elements in text/html, and ability to include SVG inline in text/html, are both features that were highly controversial and at times opposed by the editor and others. Nontheless we seem to be on track to have both of these in the spec. Note that in the case of SVG especially, the path from initial proposal to rough consensus to actual integration with the spec was a long one. In fact, integration in the spec is not yet fully complete due to some disputes about the details of the syntax. Another example is the headers attribute, and the more general issue of header association in tables. Though the headers attribute was controversial and once opposed by the editor, it is now in the spec. I believe that most of us here, while we may have our biases and preconceptions, will evaluate concrete technical arguments in good faith, and are prepared to change our minds. The fact is that people have changed positions in the past, Ian included. So nothing should be assumed to be a done deal, especially at this early stage of exploring metadata embedding and RDFa. However, the debate ended as soon as Ian re-asserted his authority. Ian just gave an indication of when he's going to work on this again. That doesn't mean that research into e.g. DOM consistency can't happen meanwhile. It also doesn't mean that debate needs to stop. No, Ian's listing of tasks pretty much precluded any input into the decision making process other than his own. I never see we when Ian writes, I only see I. Ian intends to make an evaluation based on evidence and arguments presented. Presenting such evidence and arguments is input into the decision making process. That's how other changes to the spec that went against Ian's initial gut instinct happened. Indeed it is possible for Ian to be overruled if he is clearly blocking the consensus of the group(*), but so far that has not been necessary, even on controversial issues. I encourage you to provide input into the process, and not to get too frustrated if the process is not quick. Nor by the fact that some may initially (or even finally, when all is said and done) disagree with you. Regards, Maciej * - The HTML WG can take a vote which is binding at least in the W3C context or remove Ian as editor; and the WHATWG oversight group can remove Ian as editor or pressure him by virtue of having the authority to remove him.
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 18, 2009, at 02:02, Sam Ruby wrote: On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jan 17, 2009, at 22:35, Shelley Powers wrote: Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. Also, RDFa uses CURIEs which in turn use the XML namespace mapping context. I would assume no differences in the DOM based on XHTML or HTML. The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. The W3C Recommendation for DOM also describes a readonly attribute on Attr named 'name'. Discuss. I have added this to the test cases. In the DOM API, you can use the namespace-unaware DOM Level 1 view to make both cases look the same upon getting a parser-inserted value. (This is, of course, totally against namespace-aware programming practices, and in non-browser apps, the API might not even expose qnames or higher-level technologies like RELAX NG or XPath can't trigger on them.) But it's too early to declare victory. Surely we want also scripted setters that mutate the DOM into a state that could have been the result of a parse. Now we have tentatively seen that DOM Level 1 APIs seem to do what we want. So let's try using setAttribute(): http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.html The result looks the same as the HTML case earlier: http://hsivonen.iki.fi/test/moz/xmlns-dom.html But now, the XHTML side using the setter: http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.xhtml ...gives a result that is different from the parser-inserted attribute XHTML: http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Furthermore, the resulting DOM is no longer serializable as XML 1.0. So let's move to a less intuitive case and use the namespace-aware Level 2 setter while assuming the use of the namespace-unaware Level 1 getter: http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.xhtml Looks good compared to the parser-inserted XHTML case: http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml But now, the HTML side is broken: http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.html vs. http://hsivonen.iki.fi/test/moz/xmlns-dom.html I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. There is a similar inconsistency in how xml:lang is handled. Discuss. The xml:lang DOM inconsistency has lead to a situation where the xml:lang/lang area in Validator.nu has has the highest incidence of validator buts per spec sentence of all areas of HTML5. You've reported at least one of those bugs. The amount of developer time needed to get it right was ridiculously high. fantasai recently wrote: “Unless you're working on a CSS layout engine yourself, the level of detail, complex interactions with the rest of CSS, and design and implementation constraints we need to deal with here are more complicated than you can imagine.” (Source: http://fantasai.inkedblade.net/weblog/2009/layout-is-expensive/) From my experience with Validator.nu (that doesn't even have a DOM!) I think I can say: Unless you're working on a software product whose code reuse between HTML and XHTML depends on the DOM Consistency Design principle, the badness caused by violations of the DOM Consistency Design principle is more complicated than you can imagine. (Where 'you' is not you, Sam, but the generic English you.) xml:lang was introduced by people who were designing for an XML universe when it seemed that would be the way the world would go, so they can be forgiven, and the WHATWG can clean up the mess. Likewise, the syntax that the SVG WG chose made sense given that they were designing for an XML world. It can be accepted as legacy, and HTML5 parser writers can spend time optimizing the conditional camel casing. RDFa, on the other hand, was created by people who fully expected it to be served as text/html, even though they called it something like XHTML 1.1 plus RDFa instead of calling it HTML5. Furthermore, when they saw they wanted to have RDFa in HTML5, too, instead of addressing HTML issues then, they just continued pushing towards REC. It's easily looks like this was done so that RDFa could be presented as a done deal that HTML5 needs to deal with instead of something whose details are negotiable. Creating a new mess that would have been easily avoidable is not similarly
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 17/1/09 23:30, L. David Baron wrote: On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote: The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Actually, the implementation was well underway *before* RDF was a W3C REC, done by a team led by one of the designers of RDF. In other words, it was in Gecko because there were RDF advocates at Netscape (although advocating, I think, a somewhat different RDF than the current RDF recommendations). Yes, Netscape had this stuff when it was still called MCF. W3C's RDF took ideas from several input activities, including MCF, Microsoft XML-Data, PICS, and requirements from the Dublin Core community. But it looks more like MCF than the others. MCF was originally proposed by R.V.Guha at Apple; it followed him from Apple to Netscape in 1997, and when the Mozilla sources were later thrown over the wall, there was a lot of MCF in there. MCF White Paper, 1996 http://www.guha.com/mcf/wp.html spec, http://www.guha.com/mcf/mcf_spec.html While this was at Apple, there was a product/viewer called HotSauce / Project X, and some early grassroots adoption of MCF as a text format for publishing website summaries. http://web.archive.org/web/19961224042753/http://hotsauce.apple.com/ http://downlode.org/Etext/MCF/macworld_online.html It was at this stage that dialog started with the Library scene and Dublin Core folk, about how it related to their notion of catalogue records, and to the evolving PICS labelling system, format and protocol being built at W3C. eg. http://www.ssrc.hku.hk/tb-issues/TidBITS-355.html#lnk3 http://web.archive.org/web/19980215092626/http://www.ariadne.ac.uk/issue7/mcf/ The MCF/RSS relationship is a whole other story, eg. see http://www.scripting.com/midas/mcf.html http://www.scripting.com/frontier/siteMap.mcf http://web.archive.org/web/19990222114619/http://www.xspace.net/hotsauce/sites.html Then the thing moved to Netscape. Tim Bray helped Guha XMLize the spec, which was submitted to W3C in 1997, where it joined the existing efforts to extend PICS to include text labels and more structure - http://www.w3.org/TR/NOTE-pics-ng-metadata http://www.daml.org/committee/minutes/2000-12-07-RDF-design-rationale.ppt http://searchenginewatch.com/2165291 So the June 97 spec was http://www.w3.org/TR/NOTE-MCF-XML/ .. you can see from the figures that the technology was very RDF-shaped, http://www.w3.org/TR/NOTE-MCF-XML/#sec2. Also a tutorial at http://www.w3.org/TR/NOTE-MCF-XML/MCF-tutorial.html Netscape press release accompanying June 13 1997 submission - http://web.archive.org/web/20010308150737/http://cgi.netscape.com/newsref/pr/newsrelease432.html Less than 4 months later, this came out as a W3C Working Draft called RDF: http://www.w3.org/TR/WD-rdf-syntax-971002/ ... in a shape that didn't really change much subsequently. RDF wasn't the same design exactly as MCF but the ancestry is clear enough. And getting back to the original point, yeah Mozilla had MCF sitemaps code in there. Revisiting http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104STORY=/www/story/9-8-97/312711EDATE= http://www.irt.org/articles/js086/ and the like, it's clear that RDF was very much a child of the 1st browser wars. In retrospect the direction it took within Mozilla didn't do anyone much good. The earliest MCF apps were about public data on the public Web, feeds, sitemaps and so on. But eventually the ambition to be a complete information hub led to MCF/RDF being used for pretty much everything *inside* Mozilla. And I don't think that turned out very well. http://www.mozilla.org/rdf/doc/api.html etc. The RDF vocabularies it used were poorly or never documented (I have some guilt there) and when Netscape went away, the incentive to connect to public data on the Web seemed to drop (no more tie-ins with the 'what's related' annotation server, 'dmoz' etc.). RDF drifted from being a Web data format to be consumed *by* the browser, into an engineering tool to be used in the construction *of* the browser, ie. as a datasource abstraction within Mozilla APIs. While I can certainly see the value of having a unified view of mail, news, sitemaps, and so on, the Moz code at the time wasn't really in a position to match up to the language in the press releases. Not making any particular point here beyond connecting up to the MCF heritage... cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 18/1/09 00:24, Henri Sivonen wrote: No. However, most of the time, when people publish HTML, they do it to elicit browser behavior when a user loads the HTML document in a browser. Most users of the Web barely know what a browser is, let alone HTML. They're just putting information online; perhaps into a closed site (eg. facebook), perhaps into a public-facing site (eg. a blog), or perhaps into 1:1, group or IM messaging (eg. webmail). HTML figures in all these scenarios. Browsers or HTML rendering code too, of course. But I don't think we can jump from that to claims about user intent, and more than their use of the Internet signifies an intent to have their information chopped up into packets and transmitted according to the rules of TCP/IP. The reason for my pedantry here is not to be argumentative, but just to suggest that this (otherwise very natural) thinking leads us to forget about the other major consumers of HTML - search engines. Having their stuff found and linked by other is often a big part of the motivation for putting stuff online. HTML parsing is involved, impact on the needs and interests of mainstream users is involved; but it's not clear whether all/any/many users 'do it to elicit search engine behaviour when indexing the HTML document'. Aren't search engines equally important consumers of HTML? Perhaps they're more simple-minded in their behaviour than a full UI browser. But from the user side, there's only slightly more value in being readable without being findable than vice-versa... cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, 18 Jan 2009, Dan Brickley wrote: On 18/1/09 00:24, Henri Sivonen wrote: No. However, most of the time, when people publish HTML, they do it to elicit browser behavior when a user loads the HTML document in a browser. Most users of the Web barely know what a browser is, let alone HTML. They're just putting information online; perhaps into a closed site (eg. facebook), perhaps into a public-facing site (eg. a blog), or perhaps into 1:1, group or IM messaging (eg. webmail). [...] The reason for my pedantry here is not to be argumentative, but just to suggest that this (otherwise very natural) thinking leads us to forget about the other major consumers of HTML - search engine. [...] Aren't search engines equally important consumers of HTML? Perhaps they're more simple-minded in their behaviour than a full UI browser. But from the user side, there's only slightly more value in being readable without being findable than vice-versa... Speaking at least from Google's perspective, we've found that the closer we get to emulating a browser, the better our results get. I would say that even if they don't realise it, authors are by and large acting pretty much exactly as Henri describes, and they expect their non-browser tools, such as their search engines, to just Do The Right Thing. This is reflected in the great difficulty we (the standards community) have had in convincing authors to use CSS. The mere idea that authors should mark up their text as headings and then make their headings big is often faced by the simple reply But I just want my text to be big. I'm not trying to draw any value judgements here, though. Personally I'd love it if authors could just mark up their content purely semantically and have the browsers Do The Right Thing the way that search engines have to now based on the few semantics (and ample presentational hints) that authors use. But in my experience most authors don't think that way, and aren't interested in thinking that way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Ian Hickson wrote: On Sat, 17 Jan 2009, Sam Ruby wrote: But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. For what it's worth, my current plan running up to last call in October includes an item in April for me to go through all the use cases that have by that point been put forward in the data markup space, and to work out for each use case and on the aggregate: 1. Whether there is compelling evidence that users want that use case addressed (e.g. whether there are successful companies addressing that use case using proprietary solutions or ad-hoc extensions to HTML, or whether there are usability studies or some independent market research showing demand from users, or whether it can be demonstrated that users are avoiding the Web because it doesn't address this problem). Again, you've become gatekeeper Ian. You are the one making the decision as to worth. You are the only one, as far as I can see, that is making decisions about what is, or is not included in the next version of HTML. You use I so frequently. Reading through your emails, one can't help wondering if you're the lead singer and everyone else here is nothing more than a faint echo. 2. Whether the use case is being addressed well enough already (e.g. if there are companies addressing this use case adequately, or whether the current solutions really are just hacks with numerous problems). 3. What the requirements are for each use case. 4. What solutions are available to address these use cases. 5. For each solution, whether it addresses the requirements. 6. Whether the relevant implementors are interested in implementing solutions for these use cases (e.g. whether authoring tools are willing to expose the feature, whether validator writers want to check for the correctness, whether browser vendors are willing to expose the relevant UI, whether search engine companies are willing to use the data, or whatever else might be appropriate). The more use cases there are, the better informed the results will be. The point isn't to provide use cases. The point is to highlight a serious problem with this working group--there is a mindset of what the future of HTML will look like, and the holders of the mindset brook no challenge, tolerate no disagreement, and continually move to quash any possibility of asserting perhaps even the faintest difference of opinion. My apologies for not responding sooner to this thread. You see, one of the WhatWG working group members thought it would be fun to add a comment to my Stop Justifying RDF and RDFa web post, which caused the page to break. I am using XHTML at my site, because I want to incorporate inline SVG, in addition to RDFa. An unfortunate consequence of XHTML is its less than forgiving nature regarding playful pranks such as this. I'm assuming the WhatWG member thought the act was clever. It was, indeed. Three people emailed me to let me know the post was breaking while loading the page in a browser, and I made sure to note that such breakage was courtesy of a WhatWG member, who decided that perhaps I should just shut up, here and at my site, about the Important Work people(?) here are doing. Of course, the person only highlighted why it is so important that something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML is hard to support when you're allowing comments and external input. Typically my filters will catch the accidental input of crappy markup, but not the intentional. Not yet. I'm not an exerpt at markup, but I know more than the average person. And the average person most likely doesn't have my commitment, either. Someone earlier said that HTML5 is for web application users, only, and that the rest of us interested in things like RDFa should just use XHTML. In other words, make it good for Google and to hell with the rest of us. This, this is the guiding attitude behind the future of the web? Regardless, I got the point in the comment. That, combined with this email from Ian, tells us that it doesn't matter how our arguments run, the logic of our debate, the rightness of our cause--he is the final arbiter, and he does not want RDFa. I am not paid by Google, or Mozilla, or IBM to continue throwing away my time, arguing for naught. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers shell...@burningbird.net wrote: My apologies for not responding sooner to this thread. You see, one of the WhatWG working group members thought it would be fun to add a comment to my Stop Justifying RDF and RDFa web post, which caused the page to break. I am using XHTML at my site, because I want to incorporate inline SVG, in addition to RDFa. An unfortunate consequence of XHTML is its less than forgiving nature regarding playful pranks such as this. I'm assuming the WhatWG member thought the act was clever. It was, indeed. Three people emailed me to let me know the post was breaking while loading the page in a browser, and I made sure to note that such breakage was courtesy of a WhatWG member, who decided that perhaps I should just shut up, here and at my site, about the Important Work people(?) here are doing. Of course, the person only highlighted why it is so important that something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML is hard to support when you're allowing comments and external input. Typically my filters will catch the accidental input of crappy markup, but not the intentional. Not yet. I'm not an exerpt at markup, but I know more than the average person. And the average person most likely doesn't have my commitment, either. http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by the way seems to be on your side in this debate) simply forgot to escape self-closed / and then WordPress somehow messed up in an attempt to fix it. I don't think anyone tries to make you shut up. (And if we, the evil WHATWG cabal, wanted to break your site, we would've asked Philip` ;-)) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Anne van Kesteren wrote: On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers shell...@burningbird.net wrote: My apologies for not responding sooner to this thread. You see, one of the WhatWG working group members thought it would be fun to add a comment to my Stop Justifying RDF and RDFa web post, which caused the page to break. I am using XHTML at my site, because I want to incorporate inline SVG, in addition to RDFa. An unfortunate consequence of XHTML is its less than forgiving nature regarding playful pranks such as this. I'm assuming the WhatWG member thought the act was clever. It was, indeed. Three people emailed me to let me know the post was breaking while loading the page in a browser, and I made sure to note that such breakage was courtesy of a WhatWG member, who decided that perhaps I should just shut up, here and at my site, about the Important Work people(?) here are doing. Of course, the person only highlighted why it is so important that something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML is hard to support when you're allowing comments and external input. Typically my filters will catch the accidental input of crappy markup, but not the intentional. Not yet. I'm not an exerpt at markup, but I know more than the average person. And the average person most likely doesn't have my commitment, either. http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by the way seems to be on your side in this debate) simply forgot to escape self-closed / and then WordPress somehow messed up in an attempt to fix it. I don't think anyone tries to make you shut up. (And if we, the evil WHATWG cabal, wanted to break your site, we would've asked Philip` ;-)) You're not seeing all of the markup that caused problems, Anne. The intention was to crash the post. However, I shouldn't have assumed that the person who inserted the markup that caused the problems is a WhatWG member. My apologies. Regardless of intent, it does demonstrate, again, why it is important for RDFa, SVG, and MathML find a home in HTML5. XHTML is a very difficult markup to support when you're allowing outside input. The tools do not do a good job of supporting XHTML, and hence the average person finds such failures to be intimidating, and will immediately return to HTML. Heck, I find the yellow screen of death to be unnerving myself. It's only my interest in inline SVG and RDFa, and basically distributed extensibility, that keeps me trying. And regardless of the fact that I jumped to conclusions about WhatWG membership, I do not believe I was inaccurate with the earlier part of this email. Sam started a new thread in the discussion about the issues of namespace and how, perhaps we could find a way to work the issues through with RDFa. My god, I use RDFa in my pages, and they load fine with any browser, including IE. I have to believe its incorporation into HTML5 is not the daunting effort that others make it seem to be.' However, the debate ended as soon as Ian re-asserted his authority. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers shell...@burningbird.net wrote: And regardless of the fact that I jumped to conclusions about WhatWG membership, I do not believe I was inaccurate with the earlier part of this email. Sam started a new thread in the discussion about the issues of namespace and how, perhaps we could find a way to work the issues through with RDFa. My god, I use RDFa in my pages, and they load fine with any browser, including IE. I have to believe its incorporation into HTML5 is not the daunting effort that others make it seem to be.' You ask us to take you seriously and consider your feedback, it would be nice if you took what e.g. Henri wrote seriously as well. Integrating a new feature in HTML is not a simple task, even if the new feature loads and renders fine in Internet Explorer. However, the debate ended as soon as Ian re-asserted his authority. Ian just gave an indication of when he's going to work on this again. That doesn't mean that research into e.g. DOM consistency can't happen meanwhile. It also doesn't mean that debate needs to stop. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 18/1/09 19:34, Henri Sivonen wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? I don't believe the RDFa TF are in a position to singlehandedly rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/. What they presumably could do is propose new work items within W3C, which I'd guess would be more likely to be accepted if it had the active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have something more to add. Do you have an alternative design in mind, for expressing the namespace mappings? cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, Jan 18, 2009 at 1:34 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? Just so that we have all of the data available to make an informed decision, do we have examples of how it would break the web if attributes which started with the characters xmlns: (and *only* those attribute) were placed into the DOM exactly as they would be when those bytes are processed as XHTML? Notes: I am *not* suggesting anything just yet, other than the gathering of this data. I also recognize that this would require a parsing change by browser vendors, which also is a cost that needs to be factored in. But right now, I am interested in how it would affect the web if this were done. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 18, 2009, at 20:48, Dan Brickley wrote: On 18/1/09 19:34, Henri Sivonen wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? I don't believe the RDFa TF are in a position to singlehandedly rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/ . What they presumably could do is propose new work items within W3C, which I'd guess would be more likely to be accepted if it had the active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have something more to add. Do you have an alternative design in mind, for expressing the namespace mappings? The simplest thing is not to have mappings but to put the corresponding absolute URI wherever RDFa uses a CURIE. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 18/1/09 20:07, Henri Sivonen wrote: On Jan 18, 2009, at 20:48, Dan Brickley wrote: On 18/1/09 19:34, Henri Sivonen wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? I don't believe the RDFa TF are in a position to singlehandedly rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/. What they presumably could do is propose new work items within W3C, which I'd guess would be more likely to be accepted if it had the active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have something more to add. Do you have an alternative design in mind, for expressing the namespace mappings? The simplest thing is not to have mappings but to put the corresponding absolute URI wherever RDFa uses a CURIE. So this would be a kind of interoperability profile of RDFa, where certain features approved of by REC-rdfa-syntax-20081014 wouldn't be used in some hypothetical HTML5 RDFa. If people can control their urge to use namespace abbreviations, and stick to URIs directly, would this make your DOM-oriented concerns go away? cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 18/1/09 21:04, Shelley Powers wrote: Dan Brickley wrote: On 18/1/09 20:07, Henri Sivonen wrote: On Jan 18, 2009, at 20:48, Dan Brickley wrote: On 18/1/09 19:34, Henri Sivonen wrote: On Jan 18, 2009, at 01:32, Shelley Powers wrote: Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Are the RDFa TF open to compromises that involve changing the XHTML side of RDFa not to use attribute whose qualified name has a colon in them to achieve DOM Consistency by changing RDFa instead of changing parsing? I don't believe the RDFa TF are in a position to singlehandedly rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/. What they presumably could do is propose new work items within W3C, which I'd guess would be more likely to be accepted if it had the active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have something more to add. Do you have an alternative design in mind, for expressing the namespace mappings? The simplest thing is not to have mappings but to put the corresponding absolute URI wherever RDFa uses a CURIE. So this would be a kind of interoperability profile of RDFa, where certain features approved of by REC-rdfa-syntax-20081014 wouldn't be used in some hypothetical HTML5 RDFa. If people can control their urge to use namespace abbreviations, and stick to URIs directly, would this make your DOM-oriented concerns go away? Took five minutes to make this change in my template. Ran through validator.nu. Results: Doesn't like the content-type. Didn't like profile on head. Having to remove the profile attribute in my head element limits usability, but I'm not going to throw myself on the sword for this one. Doesn't like property, doesn't like about. These are the RDFa attributes I'm using. The RDF extractor doesn't care that I used the URIs directly. This sounds encouraging. Thanks for taking the time to try the experiment, Shelley. But ... to be clear, are you putting full URIs in the @property attribute too? In http://www.w3.org/TR/rdfa-syntax/#s_curieprocessing it says '@property, @datatype and @typeof support only CURIE values.' (Can you post an example?) Reading ... Many of the attributes that hold URIs are also able to carry 'compact URIs' or CURIEs. A CURIE is a convenient way to represent a long URI, by replacing a leading section of the URI with a substitution token. It's possible for authors to define a number of substitution tokens as they see fit; the full URI is obtained by locating the mapping defined by a token from a list of in-scope tokens, and then simply concatenating the second part of the CURIE onto the mapped value. ... I guess the fact that @property is supposed to be CURIE-only isn't a problem with parsers since this can be understood as a CURIE with no (or empty) substitution token. cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, Jan 18, 2009 at 3:56 PM, Anne van Kesteren ann...@opera.com wrote: On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers shell...@burningbird.net wrote: My apologies for not responding sooner to this thread. You see, one of the WhatWG working group members thought it would be fun to add a comment to my Stop Justifying RDF and RDFa web post, which caused the page to break. I am using XHTML at my site, because I want to incorporate inline SVG, in addition to RDFa. An unfortunate consequence of XHTML is its less than forgiving nature regarding playful pranks such as this. I'm assuming the WhatWG member thought the act was clever. It was, indeed. Three people emailed me to let me know the post was breaking while loading the page in a browser, and I made sure to note that such breakage was courtesy of a WhatWG member, who decided that perhaps I should just shut up, here and at my site, about the Important Work people(?) here are doing. Of course, the person only highlighted why it is so important that something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML is hard to support when you're allowing comments and external input. Typically my filters will catch the accidental input of crappy markup, but not the intentional. Not yet. I'm not an exerpt at markup, but I know more than the average person. And the average person most likely doesn't have my commitment, either. http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by the way seems to be on your side in this debate) simply forgot to escape self-closed / and then WordPress somehow messed up in an attempt to fix it. I don't think anyone tries to make you shut up. Ouch! Thanks Anne for the screenshot, otherwise I wouldn't have known that it was my comment the one causing the issue. My apologies Shelley for that incident. I assure you that it was not intentional: it was a quite long post, I used some markup with the intention of making it more readable (like italizing the quotes), and by the end I messed things up. Thanks to the preview page I noticed some issues, like that I had to escape the sarcasm.../sarcasm for it to display (I'm too used to BBCode, which leaves unrecognized markup as is), but I didn't catch the self-closed / one (nor the preview page did: it showed up without issues). On Sun, Jan 18, 2009 at 4:15 PM, Shelley Powers shell...@burningbird.net wrote: You're not seeing all of the markup that caused problems, Anne. The intention was to crash the post. I don't really know how much did I mess up the markup on that post; and I only managed to fix the issues that I spotted from the preview page, so I wouldn't be surprised if there were more issues. Once more, I would like to clarify that this was not intentional; but, given the tension arising again from this debate, I can understand your reaction.
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Am Sonntag, den 18.01.2009, 21:30 + schrieb Eduard Pascual: On Sun, Jan 18, 2009 at 3:56 PM, Anne van Kesteren ann...@opera.com wrote: On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers shell...@burningbird.net wrote: http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by the way seems to be on your side in this debate) simply forgot to escape self-closed / and then WordPress somehow messed up in an attempt to fix it. I don't think anyone tries to make you shut up. Ouch! Thanks Anne for the screenshot, otherwise I wouldn't have known that it was my comment the one causing the issue. Which is why I disabled Wordpress autofixing. My suggestion would be: If it doesn't validate, either reject it or escape f*cking everything. (No, please don't point out that I'm using Wordpress as well and vulnerable to similar things.) On Sun, Jan 18, 2009 at 4:15 PM, Shelley Powers shell...@burningbird.net wrote: You're not seeing all of the markup that caused problems, Anne. The intention was to crash the post. I don't really know how much did I mess up the markup on that post; and I only managed to fix the issues that I spotted from the preview page, so I wouldn't be surprised if there were more issues. Once more, I would like to clarify that this was not intentional; but, given the tension arising again from this debate, I can understand your reaction. Apparently just bad Software not validating input. In the end I'm unsure what people are unruly about - anyone can explain what is the big deal ? Well-formed cheers ! -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Dan Brickley wrote: ... I guess the fact that @property is supposed to be CURIE-only isn't a problem with parsers since this can be understood as a CURIE with no (or empty) substitution token. Actually, most RDFa parsers will break if full URIs are used in RDFa attributes: in RDFa all CURIEs need a prefix which is a string of zero or more alphanumeric characters, dashes and hyphens followed by a colon (and yes, the empty string is allowed - but it is permanently bound to http://www.w3.org/1999/xhtml/vocab#). The proposed recommendation (IIRC, that's the current status) for CURIEs *does* actually allow for unprefixed CURIES, but RDFa enforces extra conditions. (As it was published before the CURIE spec, which is a spin-off of RDFa.) A suggestion I've heard for using full URIs is: html xmlns:http=http: title property=http://purl.org/dc/terms/title;Foo/title /html Which should theoretically work according to the reference algorithm in the RDFa syntax document, however it does (I believe) break the XML Namespaces spec. (Though that wouldn't be a problem if an alternative, non-xmlns, syntax were adopted for CURIE prefix binding.) It wouldn't surprise me if a few RDFa parsers had issues with this caused by the front-end XML parser they use. So RDFa, as it is currently defined, does need a CURIE binding mechanism. XML namespaces are used for XHTML+RDFa 1.0, but given that namespaces don't work in HTML, an alternative mechanism for defining them is expected, and for consistency would probably be allowed in XHTML too - albeit in a future version of XHTML+RDFa, as 1.0 is already finalised. (I don't speak for the RDFa task force as I am not a member, but I would be surprised if many of them disagreed with me strongly on this.) Back to when I said most RDFa parsers will break if full URIs are used in RDFa attributes. The Perl library RDF::RDFa::Parser doesn't, so if you want to do any testing with full URIs, it can be found on CPAN. Full URIs are a pain to type though - I certainly prefer using CURIEs. -- Toby A Inkster mailto:m...@tobyinkster.co.uk http://tobyinkster.co.uk
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sun, 18 Jan 2009, Shelley Powers wrote: The more use cases there are, the better informed the results will be. The point isn't to provide use cases. The point is to highlight a serious problem with this working group--there is a mindset of what the future of HTML will look like, and the holders of the mindset brook no challenge, tolerate no disagreement, and continually move to quash any possibility of asserting perhaps even the faintest difference of opinion. I'm certainly sad that this is the impression I have given. I'd like to clarify for everyone's sake that this mailing list is definitely open to any proposals, any opinions, any disagreement. The only thing I ask is that people use rational debate, back up their opinions with logical arguments, present research to justify their claims, and derive proposals from user needs. Regardless, I got the point in the comment. That, combined with this email from Ian, tells us that it doesn't matter how our arguments run, the logic of our debate, the rightness of our cause--he is the final arbiter, and he does not want RDFa. For the record, I am as open to us including a feature like RDFa as I am to us including a feature like MathML, SVG, or indeed anything else. While I may present a devil's advocate position to stimulate critical consideration of proposals, this does not mean that my mind is made up. If my mind was made up, I wouldn't be asking for use cases, and I wouldn't be planning to investigate the issue further in April. I am not paid by Google, or Mozilla, or IBM to continue throwing away my time, arguing for naught. It may be worth pointing out that, many of our most active participants are volunteers, not paid by anyone to participate. Indeed I myself spent many years contributing to the standards community while unemployed or while a student. I am sorry you feel that you need to be compensated for your participation in the standards community, and wish you the best of luck in finding a suitable employer. As far as Google goes, we have no corporate opinion either way on the topic of RDFa in HTML5. We do, however, encourage the continued practice of basing decisions on data rather than hopes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
The debate about RDFa highlights a disconnect in the decision making related to HTML5. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. An earlier email between Martin Atkins and Ian Hickson had the following: On Sun, 11 Jan 2009, Martin Atkins wrote: One problem this can solve is that an agent can, given a URL that represents a person, extract some basic profile information such as the person's name along with references to other people that person knows. This can further be applied to allow a user who provides his own URL (for example, by signing in via OpenID) to bootstrap his account from existing published data rather than having to re-enter it. So, to distill that into a list of requirements: - Allow software agents to extract profile information for a person as often exposed on social networking sites from a page that represents that person. - Allow software agents to determine who a person lists as their friends given a page that represents that person. - Allow the above to be encoded without duplicating the data in both machine-readable and human-readable forms. Is this the sort of thing you're looking for, Ian? Yes, the above is perfect. (I cut out the bits that weren't really the problem from the quote above -- the above is what I'm looking for.) The most critical part is allow a user who provides his own URL to bootstrap his account from existing published data rather than having to re-enter it. The one thing I would add would be a scenario that one would like to be able to play out, so that we can see if our solution would enable that scenario. For example: I have an account on social networking site A. I go to a new social networking site B. I want to be able to automatically add all my friends from site A to site B. There are presumably other requirements, e.g. site B must not ask the user for the user's credentials for site A (since that would train people to be susceptible to phishing attacks). Also, site A must not publish the data in a manner that allows unrelated users to obtain privacy-sensitive data about the user, for example we don't want to let other users determine relationships that the user has intentionally kept secret [1]. It's important that we have these scenarios so that we can check if the solutions we consider are actually able to solve these problems, these scenarios, within the constraints and requirements we have. It would seem that Ian agrees with a need to both a) provide a way to document complex information in a consistent, machine readable form and that b) the purpose of this data is for external consumption, rather than internal use. Where the disconnect comes in is he believes that RDF, and the web page serialization technique, RDFa, are only one of a set of possible solutions. Yet at the same time, he references how the MathML and SVG people provide sufficient use cases to justify the inclusion of both of these into HTML5. But what is MathML. What does it solve? A way to include mathematical formula into a document in a formatted manner. What is SVG? A way to embed vector graphics into a web page, in such a way that the individual elements described by the graphics can become part of the overall DOM. So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? So, why accept that we have to use SVG in order to solve the problems of vector graphics? Why not start from scratch, and devise a new approach? Come to think of it, I think we should also question the use of the canvas element. After all, if the problem set is that we need the ability to animate graphics in a web page using a non-proprietary technology, then wouldn't something like SVG work for this purpose? Isn't the canvas element redundant? But then, perhaps we should start over from the beginning and just create a new graphics capability from scratch, and reject both canvas and SVG. We don't reject MathML, though. Neither do we reject SVG or canvas. Or any other of a number of entities being included in HTML5, including SQL. Why? Because they have a history of use, extensive documentation as to purpose and behavior, and there are a considerable number of implementations that support the specifications. It doesn't make sense to start from scratch. It makes more sense to make use of what already works. I have to ask, then: why do we isolate RDF, and RDFa for special handling? If we can accept that SQL is a natural database query mechanism, and SVG is a natural for
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. cheers, Dan -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Dan Brickley wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. cheers, Dan I agree, and appreciate Dan for pointing out a specific instance of use. Apologies for not making the assertion explicit. Shelley -- http://danbri.org/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. The fact that this works anywhere at all today implies that little, if any, changes to browsers is required in order to support this. Is that a fair statement? I've not taken a look at the code, but have taken a quick glance at the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome 1.0.154.43, Opera 9.63, and Firefox 3.0.5. The page is different (as in less functional) under IE8 and Safari. Is there something that they need to do which is not already covered in the HTML5 specification in order to support this? - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, 17 Jan 2009, Sam Ruby wrote: Shelley Powers wrote: So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. Sam's point here bears repeating, because there seems to be an impression that we took on SVG and MathML without any consideration, while RDF is getting an unfair reception. On the contrary, SVG and MathML got the same reception. For MathML, for instance, a number of options were very seriously considered, most notably LaTeX. For SVG, we considered a variety of options including VML. I would encourage people to read the e-mail Sam cited: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html It's long, but the start of it is a summary of what was considered and shows that the same process derived from use cases was used for SVG and MathML as is being used on this thread here. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Sam Ruby wrote: On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote: On 17/1/09 19:27, Sam Ruby wrote: On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers shell...@burningbird.net wrote: The debate about RDFa highlights a disconnect in the decision making related to HTML5. Perhaps. Or perhaps not. I am far from an apologist for Hixie, (nor for that matter and I a strong advocate for RDF), but I offer the following question and observation. The purpose behind RDFa is to provide a way to embed complex information into a web document, in such a way that a machine can extract this information and combine it with other data extracted from other web pages. It is not a way to document private data, or data that is meant to be used by some JavaScript-based application. The sole purpose of the data is for external extraction and combination. So, I take it that it isn't essential that RDFa information be included in the DOM? This is not rhetorical: I honestly don't know the answer to this question. Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. The fact that this works anywhere at all today implies that little, if any, changes to browsers is required in order to support this. Is that a fair statement? I've not taken a look at the code, but have taken a quick glance at the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome 1.0.154.43, Opera 9.63, and Firefox 3.0.5. The page is different (as in less functional) under IE8 and Safari. Is there something that they need to do which is not already covered in the HTML5 specification in order to support this? I would think we would have to go through the code to see what this specific instance of client-side access of the RDFa isn't working. The debugger I'm using with IE8 shows the problem is occuring in the jQuery code, not necessarily anything specific to the RDFa plugin. I know other JavaScript libraries that work with RDFa work, at least with Safari. For instance: http://www.w3.org/2006/07/SWD/RDFa/impl/js/ Since this library was vetted for IE7, would assume it would work for IE8, too. Of course, the RDFa attributes aren't incorporated into HTML5, which means their use would result in an invalid document. And of course, if they were incorporated, the issue of namespace for them would have to be addressed as namespaces were for MathML and SVG. Shelley - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 20:33, Dan Brickley wrote: Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. Does this code run the same way on both DOMs parsed from text/html and application/xhtml+xml in existing browsers without at any point branching on a condition that is a DOM difference between text/html- originated and application/xhtml+xml-originated DOMs? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Ian Hickson wrote: On Sat, 17 Jan 2009, Sam Ruby wrote: Shelley Powers wrote: So, why accept that we have to use MathML in order to solve the problems of formatting mathematical formula? Why not start from scratch, and devise a new approach? Ian explored (and answered) that here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html Key to Ian's decision was the importance of DOM integration for this vocabulary. If DOM integration is essential for RDFa, then perhaps the same principles apply. If not, perhaps some other principles may apply. Sam's point here bears repeating, because there seems to be an impression that we took on SVG and MathML without any consideration, while RDF is getting an unfair reception. On the contrary, SVG and MathML got the same reception. For MathML, for instance, a number of options were very seriously considered, most notably LaTeX. For SVG, we considered a variety of options including VML. I would encourage people to read the e-mail Sam cited: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html It's long, but the start of it is a summary of what was considered and shows that the same process derived from use cases was used for SVG and MathML as is being used on this thread here. I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. The fact that it is based on RDF, a mature, well documented, widely used model with many different implementations is a perk. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Henri Sivonen wrote: On Jan 17, 2009, at 20:33, Dan Brickley wrote: Good question. I for one expect RDFa to be accessible to Javascript. http://code.google.com/p/rdfquery/wiki/Introduction - http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice example of code that does something useful in this way. Does this code run the same way on both DOMs parsed from text/html and application/xhtml+xml in existing browsers without at any point branching on a condition that is a DOM difference between text/html-originated and application/xhtml+xml-originated DOMs? I don't want to specifically look at just the one case, since it is not working in Safari, and IE8 and is too complex to debug right at this moment. Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. I would assume no differences in the DOM based on XHTML or HTML. The one issue that would occur has to do with the values assigned, not the syntax. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page, http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. Access the page using Firefox, which is served the page as XHTML. Access it as IE8, which gets the page as HTML. You can tell the difference between my graphics are based in inline SVG, and will only show if the page is served as XHTML. So, yes, with my quick, crude demonstration, DOM access is the same in both environments. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Henri Sivonen wrote: On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Now wait a second, you're changing the parameters of the requirements. Before, the criteria was based on the DOM. Now you're saying that the browsers actually have to do with something with it. Who is to say what the browsers will do with RDF in the future? In addition, is that the criteria for pages on the web -- that every element in them has to result in different behaviors in browsers, only? What about other user agents? That seems to me to be looking for RDFa sized holes and them throwing them into the criteria, specifically to trip up RDF, and hence, RDFa. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. SVG and MathML were both created as XML, and hence were not vetted for text/html, either. And yet, here they are. Well, here they'll be, eventually. Come to that -- I don't think the creators of SQL actually ever expected that someday SQL queries would be initiated from HTML pages. Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
Sam Ruby wrote: On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. I am patient. Look at me? I make extensive use of both SVG and RDF -- that is the mark of a patient woman. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. First of all, whatever happens has to happen with either vetting by the RDF/RDFa folks, if not their active help. This is my way of saying, I'd be willing to do much of the legwork, but I want to make I don't represent RDFa incorrectly. Secondly, my finances have been caught up in the current downturn, and my first priority has to be on the hourly work and odd jobs I'm getting to keep afloat. Which means that I can't always guarantee 20+ hours a week on a task, nor can I travel. Anywhere. But if both are acceptable conditions, I'm willing to help with tasks. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. Tasks including this one. Shelley - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 3:51 PM, Shelley Powers shell...@burningbird.net wrote: Sam Ruby wrote: On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers shell...@burningbird.net wrote: I propose that RDFa is the best solution to the use case Martin supplied, and we've shown how it is not a disruptive solution to HTML5. Others may differ, but my read is that the case is a strong one. But I will caution you that a little patience is in order. SVG is not a done deal yet. I've been involved in a number of standards efforts, and I've never seen a case of proposed on a Saturday morning, decided on a Saturday afternoon. One demo is not conclusive. Now you mention that there exists a number of libraries. I think that's important. Very important. Possibly conclusive. I am patient. Look at me? I make extensive use of both SVG and RDF -- that is the mark of a patient woman. But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. If, however, some of the legwork is done for Ian, this may help accelerate the effort. First of all, whatever happens has to happen with either vetting by the RDF/RDFa folks, if not their active help. This is my way of saying, I'd be willing to do much of the legwork, but I want to make I don't represent RDFa incorrectly. Secondly, my finances have been caught up in the current downturn, and my first priority has to be on the hourly work and odd jobs I'm getting to keep afloat. Which means that I can't always guarantee 20+ hours a week on a task, nor can I travel. Anywhere. But if both are acceptable conditions, I'm willing to help with tasks. I don't see any of that as being a problem. Even little things may help a lot. I know what I'm about to say may be unpopular, but I'll say it anyway: take a few good examples of RDFa and run them through Henri's validator. The validator will helpfully indicate exactly what areas of the spec would need to be updated in order to accommodate RDFa. The next step would be to take a look at those sections. If the update is obvious and straightforward, perhaps nothing more is required. But if not, researching into the options and making recommendations may help. Tasks including this one. Excellent. Well, all except for the downturn thing, but you know what I mean. In order to prevent any misunderstandings: it is not for me to assign work. In fact, nobody here is in such a position. People simply note things that need to be done, and do the ones that interest them, at the pace at which they are able. And communicate copiously. If you need help in vetting, I am given to understand that there is a small pocket of RDF enthusiasm in the W3C. :-P Shelley - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote: The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Actually, the implementation was well underway *before* RDF was a W3C REC, done by a team led by one of the designers of RDF. In other words, it was in Gecko because there were RDF advocates at Netscape (although advocating, I think, a somewhat different RDF than the current RDF recommendations). Compare the dates on: http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/ http://www.w3.org/TR/1999/PR-rdf-schema-19990303/ http://bonsai.mozilla.org/cvsquery.cgi?treeid=defaultmodule=allbranch=HEADbranchtype=matchdir=mozilla%2Frdffile=filetype=matchwho=whotype=matchsortby=Datehours=2date=explicitmindate=1998-01-01maxdate=1999-01-01cvsroot=%2Fcvsroot -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 22:35, Shelley Powers wrote: Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. Also, RDFa uses CURIEs which in turn use the XML namespace mapping context. I would assume no differences in the DOM based on XHTML or HTML. The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Jan 17, 2009, at 22:43, Shelley Powers wrote: Henri Sivonen wrote: On Jan 17, 2009, at 21:38, Shelley Powers wrote: I'm not doubting the effort that went into getting MathML and SVG accepted. I've followed the effort associated with SVG since the beginning. I'm not sure if the same procedure was also applied to the canvas object, as well as the SQL query capability. Will assume so. Note that SVG, MathML and SQL have had different popularity trajectories in top four browser engines than RDF. SVG is going up. At the time it was included in HTML5 (only to be commented out shortly thereafter), three of the top browser engines implemented SVG for retained-mode vector graphics and their SVG support was actively being improved. (One of the top four engines implemented VML, though.) At the time MathML was included in HTML5, it was supported by Gecko with renewed investment into it as part of the Cairo migration. Also, Opera added some MathML features at that time. Thus, two of the top four engines had active MathML development going on. Further, one of the major MathML implementations is an ActiveX control for IE. When SQL was included in HTML5, Apple (in WebKit) and Google (in Gears) had decided to use SQLite for this functionality. Even though Firefox doesn't have a Web-exposed database, Firefox also already ships with embedded SQLite. At that point it would have been futile for HTML5 to go against the flow of implementations. The story of RDF is very different. Of the top four engines, only Gecko has RDF functionality. It was implemented at a time when RDF was a young W3C REC and stuff that were W3C RECs were implemented less critically than nowadays. Unlike SVG and MathML, the RDF code isn't actively developed (see hg logs). Moreover, the general direction seems to be away from using RDF data sources in Firefox internally. Now wait a second, you're changing the parameters of the requirements. I'm explaining how SVG, MathML and SQL are different from RDF(a) in a way that's very relevant to the practice of including stuff in the spec. Before, the criteria was based on the DOM. Now you're saying that the browsers actually have to do with something with it. Who is to say what the browsers will do with RDF in the future? http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016045.html is a message where one of the editors of RDFa mentions RDFa together with client-side tools like Ubiquity. That Ubiquity is a Firefox extension rather than part of the core feature set is an implementation detail. I read this as envisioning browser-sensitivity to RDFa. In addition, is that the criteria for pages on the web -- that every element in them has to result in different behaviors in browsers, only? No. However, most of the time, when people publish HTML, they do it to elicit browser behavior when a user loads the HTML document in a browser. Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec community knowingly moved away from RDF with RSS 2.0 and Atom. Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is treated as XML instead. If RSS 1.0 is evidence, it's evidence *against* RDF. The point I'm making is that you set a precedent, and a good one I think: giving precedence to not invented here. In other words, to not re-invent new ways of doing something, but to look for established processes, models, et al already in place, implemented, vetted, etc, that solve specific problems. Now that you have accepted a use case, Martin's, and we've established that RDFa solves the problem associated with the use case, the issue then becomes is there another data model already as vetted, documented, implemented that would better solve the problem. Clearly, RDFa wasn't properly vetted--as far as the desire to deploy it in text/html goes--when the outcome was that it ended up using markup that doesn't parse into the DOM the same way in HTML and XML. SVG and MathML were both created as XML, and hence were not vetted for text/html, either. And yet, here they are. Well, here they'll be, eventually. Actually, the creators of MathML had the good sense and foresight to avoid name collisions with HTML even after Namespaces theoretically gave them a permission not to care. Unlike the creators of RDFa, the creators of SVG weren't pushing for inclusion in HTML5 or saying that it's OK to serve their XML as text/ html--quite the contrary. And the integration would have been nicer if the SVG WG had had the same prudence as the Math WG. Come to that -- I don't think the creators of SQL actually ever expected that someday SQL queries would be initiated from HTML pages. I don't see the creators of SQL asking for the inclusion of their stuff in HTML after building on another spec that is well-known to be trouble with HTML (Namespaces in XML in
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. And I also said that we would have to address the issue of namespaces, which actually may require additional effort. I said that the addition of RDFa would mean the addition of some attributes, and we would have to deal with namespace issues. Just like the HTML5 working group is having to deal with namespaces with MathML and SVG. And probably the next dozen or so innovations that come along. That is the price for not having distributed extensibility. One works the issues. I assume the same could be said of any many of the newer additions to HTML5. Are you then saying that this will be a showstopper, and there will never be either a workaround or compromise? Shelley
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen hsivo...@iki.fi wrote: On Jan 17, 2009, at 22:35, Shelley Powers wrote: Generally, though, RDFa is based on reusing a set of attributes already existing in HTML5, and adding a few more. Also, RDFa uses CURIEs which in turn use the XML namespace mapping context. I would assume no differences in the DOM based on XHTML or HTML. The assumption is incorrect. Please compare http://hsivonen.iki.fi/test/moz/xmlns-dom.html and http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml Same bytes, different media type. The W3C Recommendation for DOM also describes a readonly attribute on Attr named 'name'. Discuss. I put together a very crude demonstration of JavaScript access of a specific RDFa attribute, about. It's temporary, but if you go to my main web page,http://realtech.burningbird.net, and look in the sidebar for the click me text, it will traverse each div element looking for an about attribute, and then pop up an alert with the value of the attribute. I would use console rather than alert, but I don't believe all browsers support console, yet. This misses the point, because the inconsistency is with attributes named xmlns:foo. There is a similar inconsistency in how xml:lang is handled. Discuss. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/ - Sam Ruby
Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
On Sat, 17 Jan 2009, Sam Ruby wrote: But back to expectations. I've seen references elsewhere to Ian being booked through the end of this quarter. I may have misheard, but in any case, my point is the same: if this is awaiting something from Ian, it will be prioritized and dealt with accordingly. For what it's worth, my current plan running up to last call in October includes an item in April for me to go through all the use cases that have by that point been put forward in the data markup space, and to work out for each use case and on the aggregate: 1. Whether there is compelling evidence that users want that use case addressed (e.g. whether there are successful companies addressing that use case using proprietary solutions or ad-hoc extensions to HTML, or whether there are usability studies or some independent market research showing demand from users, or whether it can be demonstrated that users are avoiding the Web because it doesn't address this problem). 2. Whether the use case is being addressed well enough already (e.g. if there are companies addressing this use case adequately, or whether the current solutions really are just hacks with numerous problems). 3. What the requirements are for each use case. 4. What solutions are available to address these use cases. 5. For each solution, whether it addresses the requirements. 6. Whether the relevant implementors are interested in implementing solutions for these use cases (e.g. whether authoring tools are willing to expose the feature, whether validator writers want to check for the correctness, whether browser vendors are willing to expose the relevant UI, whether search engine companies are willing to use the data, or whatever else might be appropriate). The more use cases there are, the better informed the results will be. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'