On Fri, Jan 2, 2009 at 11:55 AM, Julian Reschke <julian.resc...@gmx.de> wrote: > Tab Atkins Jr. wrote: >> >> ... >> Solutions for this already exist; embedded N3 in a <script> tag, just >> to name something that Ian already mentioned, allows you to mash RDF >> data into a page in a machine-extractable way, and brings in any of >> the specific ancillary benefits of RDF. >> ... > > Well, it'll require an N3 parser where previously none was needed.
RDFa requires an RDFa parser as well, and in general *any* metadata requires a parser, so this point is moot. The only metadata that doesn't require a parser is no metadata at all. > Also, it > separates the metadata from the text, a situation most people want to avoid. That sounds like a requirement, but it's one that already presumes that metadata is useful to embed in webpages. It has not yet been established that there is a problem worth solving that metadata would address at all. (Clarifying this was the primary purpose of Ian's mail, and my first mail in this thread.) > This may work, but as far as I can tell, the use of <script> for "data > blocks" is an afterthought -- for instance, it's described in a section > about, well, Scripting. > > So, is anybody using this successfully in practice? I have no idea. The point is, though, that it *is* an existing possibility that requires no further effort from this working group or browser developers. As such, if it solves the problem (whatever it is, since that hasn't yet been well-established) sufficiently, we can leave it alone. It is in the best interests of everybody if a solution can be found without any changes to the language, because it means browser uptake is quick (immediate and retroactive, to be precise ^_^). We have to ensure that the problem isn't already solved by the language first, and only after that can we evaluate whether the language is the correct place to solve the problem, and only after *that* can we start discussing how to actually go about solving the problem in the language. Too much of this discussion is jumping straight to step 3, so Ian, I, and others are trying to focus it on step 1. >> ... >> Not quite correct. Again, the problem of embedded shareable data in a >> web page has been solved multiple times. The specific problem of >> sharing *RDF* data (due to needing/wanting the specific benefits RDF >> can offer) has also been solved. What are the precise problems that >> require *RDFa* as a solution? >> ... > > Could you elaborate a bit on these solutions? Microformats, embedded data in <script> blocks, embedded XML, custom attributes, other miscellaneous uses of @class and related attributes, and simply putting the data in natural language. These solutions already exist, and in several cases are easier to use than RDFa. Do they have specific failings that RDFa addresses? Are these failings significant enough to warrant extending the language to solve them? To we *understand* the failings (assuming they exist and are significant) well enough to be confident we can solve them correctly in the language, rather than waiting for the community to solve them themselves and then simply reifying their solutions? > My understanding was that RDFa has been produced in order to address > problems with other approaches, such as using <meta> elements, eRDF, or > microformats. > > If there is a *successful* alternative to RDFa that does not require new > attributes, please let us know :-). The most successful alternative is nothing at all. ^_^ We can extract copious data from web pages reliably without metadata, either using our human senses (in personal use) or natural-language-based processing (in search engine use). It has not yet been established that sufficient and significant enough problems *exist* to justify a solution, let alone one that requires an addition to html. That is what Ian is specifically looking for. Unfortunately, you really do need to justify metadata anew; you can't just point at Microformats or something similar and say "we're doing the same things as those guys!". They exist currently because they can fit their solutions into the language as it is; there is no further need to justify them in this group. Modifying the language, though, is an explicit admission that this is a problem worth solving and worth solving in a particular way, and so requires significant justification. >> ... >> Well, there are many things that would offer more advantages than >> disadvantages by themselves. We can't possibly include all of them in >> the spec; you can think about this as including a hidden large >> disadvantage of 'will grow the size of the spec and the amount of work >> implementors have to do'. Thus the advantages must generally be >> significantly larger than the disadvantages; this is why the best >> argument for including something in the spec is often "there are >> already widespread hacks to accomplish this". <video>, for example, >> was included based on pretty much precisely that argument. >> ... > > Reminder: RDFa is one of the things the (W3C) Working Group's Charter > mentions as candidate for inclusion (either by a generic extensibility > mechanism, or otherwise by extending the language): > > "The HTML WG is encouraged to provide a mechanism to permit independently > developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and > RDFa to be mixed into HTML documents." > <http://www.w3.org/2007/03/HTML-WG-charter.html#other> As a note, this isn't the W3C's HTML WG. The WHATWG is independent from the W3C. ~TJ
