This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The use of prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of string is IMHO too complicated for a technology intended for broad Web deployment (e.g. in text/html). I sent comments to this effect to the list: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Aug/0035.html HTML5+RDFa uses such a model (layered on top of the "xmlns" attributes currently, though it doesn't matter exactly what the prefix declaration attribute is). I think this should be a blocker issue for any HTMLWG deliverable.
I disagree with that statement. Prefix-based lookup is similar in complexity to the classname / element name based lookup used in CSS. Also, although it's complex it's a complexity that many have learned to deal with anyway in other languages.
It seems like Ian is arguing about a train that has left station already: RDFa is already in use in text/html today. It doesn't matter that most of those pages are formally XHTML pages (according to their doctype).
The Internet is rife with examples of 'prefixing' mechanisms that seem to work just fine. RDFa is not the first example of this, nor will it be the last. Moreover, RDFa+XHTML is already in wide use, including adoption by major players (e.g., Yahoo!, Google). Clearly those people think this solution is not too complex. Note also that the RDFa Task Force continues to discuss and define a mechanism that would permit the definition of collections of prefix names and the extension of the collection of 'reserved words' dynamically. Such a mechanism will make it even easier for people to use this technology, since they will most likely be able to bring in common vocabularies via a sigle, simple reference. This extension, if it gets done, will be 100% backward compatible with the existing deployed pages, so no risk there. All in all, I think the prefixing that RDFa relies upon is an essential part of the technology, and that the users of RDFa seem to have no trouble grokking that part of it.
(In reply to comment #3) > The Internet is rife with examples of 'prefixing' mechanisms that seem to work > just fine. Could you give examples, please? > Moreover, RDFa+XHTML is already in wide use, including adoption by major > players (e.g., Yahoo!, Google). Clearly those people think this solution is > not too complex. According to http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0124.html and http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html Google isn't implementing prefix-based indirection in their support of "RDFa".
(In reply to comment #4) > (In reply to comment #3) > > The Internet is rife with examples of 'prefixing' mechanisms that seem to work > > just fine. > > Could you give examples, please? Sure. RDF/XML, N3, Office Open XML, URIs (IRIs etc), RSS, ATOM, Java, JavaScript, PHP, Perl. I respect that your request for expansion was a troll, but seriously... the use of "references" via defined identifiers is a basic concept in computer science. If you are trying to argue that computer scientists don't author web pages... I am sure a lot of web page authors are not computer scientists. That doesn't mean they are too stupid to grok the basic mathematical concept that "x" can equal "something longer than x". Give me a break. > > > Moreover, RDFa+XHTML is already in wide use, including adoption by major > > players (e.g., Yahoo!, Google). Clearly those people think this solution is > > not too complex. > > According to > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0124.html > and > http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html > Google isn't implementing prefix-based indirection in their support of "RDFa". > While their implementation may have some bugs (as does mine), I am sure they fully intend to support the required features of RDFa. I suggest you take it up with them if you are concerned. Firefox doesn't correctly support all of HTML 4.01 - does that invalidate it as an example of a web browser? I don't think so.
> Prefix-based lookup is similar in complexity to > the classname / element name based lookup used in CSS. CSS selector indirection is already pretty confusing to a lot of authors, but it has three advantages that don't apply to RDFa: errors don't cause bad data to be generated, selectors can be written by trial and error without the use of tools beyond a browser, and it's not a rebindable prefix mechanism. > Sure. RDF/XML Not in use in any sort of wide scale, and equally bad. > N3 Not in use in any sort of measurable scale. > Office Open XML Not hand-authored. > URIs (IRIs etc) Doesn't use a rebindable prefix mechanism. > RSS Not in use in a way that uses a rebindable prefix mechanism. > ATOM Not in use in a way that uses a rebindable prefix mechanism. > Java, JavaScript, PHP, Perl. Doesn't use rebindable prefixes that are combined with a second string to form a third string whose value matters in a way that it could be constructed in any arbitrary other ways. > I think the prefixing that RDFa relies upon is an essential part of > the technology Then I think we should not have the technology. > and that the users of RDFa seem to have no trouble grokking > that part of it I think that the HTMLWG should be designing technologies for orders of magnitude more usage than RDFa current has.
(In reply to comment #6) > > ATOM > > Not in use in a way that uses a rebindable prefix mechanism. That is incorrect. I recall discussions about certain clients failing to process namespaces correctly; a prominent one was Google Reader. But that problem was fixed with a few weeks after the bug report was submitted (I can dig out the details, it was me submitting the bug report).
(In reply to comment #6) Ian, I appreciate that you don't like this technology, and that your vision doesn't include something that is arbitrarily extensible. I and others disagree with you. You claimed (in the subject of this bug report) that "Use of prefixes is too complicated for a Web technology". I mentioned a number of technologies that are widely deployed on the web. You then attempted to disqualify those examples as uninteresting. This is a classic technique in debates, but I am going to have to call "bullshit" on it. All of the examples I cited support prefixing (or the creation of references that map to other symbols). All of them are deployed on the web. Every new technology starts out with the same amount of adoption - zero. Over time, that number will increase. RDFa is young, but it already has adoption significantly higher than zero. And all of that adoption uses the simple prefixing technique that XML Namespaces introduced. Beyond that, RDFa is a W3C Recommendation that has the support of the semantic web community. Is it perfect? Of course not. Is it complete yet? Of course not. Does that mean that we should ignore it and deploy some other, less capable technology with no semantic web community support in HTML5? I don't think so. But this issue goes WAY beyond RDFa. It goes to the heart of the issue of extensibility. The W3C's vision for the architecture of the web relies upon decentralized extensibility. The ability for anyone to define a grammar and incorporate that grammar in to their markup. RDFa supports this architecture - and one of the ways it does so is by incorporating the basic concept that "x" means "something longer than x", and allowing the content author to define both of those things. I won't apologize for supporting that concept. Shame on you for trying to dumb down the web by not supporting it.
The problems with prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of string are documented and demonstrable. The examples you gave are either things that don't use such prefixes (like URIs), or that do and have not had anywhere near the level of deployed success that HTML has (like XML namespaces). This bug is not arguing against RDFa. It's arguing against a particular design decision in RDFa that is not intrinsic to RDFa's design goals. This bug has nothing to do with whether extensibility is a good idea or not.
(In reply to comment #9) > The problems with prefixes that can be bound to arbitrary strings then combined > with other strings to form a third set of string are documented and > demonstrable. The examples you gave are either things that don't use such > prefixes (like URIs), or that do and have not had anywhere near the level of > deployed success that HTML has (like XML namespaces). > ... How is it relevant whether a specific technology has the same level of "deployed success"? And it it's relevant, why does HTML5 include tons of stuff that hasn't any "deployed success" at all?
> How is it relevant whether a specific technology has the same level of > "deployed success"? If you're trying to work out whether a technology is usable or not, then it being successful or not is a useful indicator. > And it it's relevant, why does HTML5 include tons of stuff that hasn't any > "deployed success" at all? The things that haven't had much deployed success are either obsoleted (like profile="") or mostly harmless (like <kbd>). As far as I know, none of the new features rely on design patterns that we have reason to believe won't succeed. If I'm wrong about this, please file bugs about them.
(In reply to comment #11) > > How is it relevant whether a specific technology has the same level of > > "deployed success"? > > If you're trying to work out whether a technology is usable or not, then it > being successful or not is a useful indicator. Depends on a certain definition of "successful". Is WebDAV successful? Is Atom? Is JCR? Is CMIS? Is Docbook? Is XSLT? > > And it it's relevant, why does HTML5 include tons of stuff that hasn't any > > "deployed success" at all? > > The things that haven't had much deployed success are either obsoleted (like > profile="") or mostly harmless (like <kbd>). As far as I know, none of the new > features rely on design patterns that we have reason to believe won't succeed. > If I'm wrong about this, please file bugs about them. Microdata. Ping. And probably lots more I haven't noticed yet.
> > > How is it relevant whether a specific technology has the same level of > > > "deployed success"? > > > > If you're trying to work out whether a technology is usable or not, then it > > being successful or not is a useful indicator. > > Depends on a certain definition of "successful". Is WebDAV successful? Is Atom? > Is JCR? Is CMIS? Is Docbook? Is XSLT? It's not a binary question. None of those technologies other than Atom is hand-authored and as widely deployed as HTML. As far as I am aware, no technology that uses the anti-pattern described above is as widely used as HTML. Plenty of other technologies that _don't_ use the anti-pattern _are_, like CSS, JS, HTTP, DOM, etc. It's naïve to invent new technologies without learning the lessons from the failures of past technologies. Outright _denying_ the failures is even worse, though. The HTML WG's deliverables are all about learning the lessons from the past (e.g. realising the importance of backwards compatibility instead of boiling the oceans like XHTML2 and XForms, being detailed about implementation details instead of vague like HTML4 and DOM2 HTML, not making technologies too complex for authors, etc). I would not support this working group publishing a technology that made as fundamental a mistake as using user-declared string-bound prefixes to form identifiers. > Microdata. Ping. And probably lots more I haven't noticed yet. "Things you don't like" is not the same as "things that rely on design patterns that we have reason to believe won't succeed". You haven't listed patterns that those features rely on that would cause those features to fail, you've just pointed out non-technical reasons you don't like them and places that you (mistakenly) think they violate other specifications.
(In reply to comment #5) > I am sure they > fully intend to support the required features of RDFa. I'm not so sure they intend to do so, given this statement: "But we will also deviate from the standard" http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html
(In reply to comment #7) > (In reply to comment #6) > > > ATOM > > > > Not in use in a way that uses a rebindable prefix mechanism. > > That is incorrect. I recall discussions about certain clients failing to > process namespaces correctly; a prominent one was Google Reader. But that > problem was fixed with a few weeks after the bug report was submitted (I can > dig out the details, it was me submitting the bug report). That clients failed to do it correctly is an indicator that content didn't use the rebindable prefix mechanism. That some of them were fixed is not proof that content use the rebindable prefix mechanism now.
(In reply to comment #15) > That clients failed to do it correctly is an indicator that content didn't use > the rebindable prefix mechanism. (It is also an indicator that implementors might get rebindable prefix mechanism wrongly implemented or not implemented at all from the start, maybe because they find it too complex to implement or maybe because they deliberately ignore it.)
(In reply to comment #16) > (In reply to comment #15) > > > That clients failed to do it correctly is an indicator that content didn't use > > the rebindable prefix mechanism. It is an indicator that most content used the same prefixes. Some didn't, thus the bug was discovered, and fixed. > (It is also an indicator that implementors might get rebindable prefix > mechanism wrongly implemented or not implemented at all from the start, maybe > because they find it too complex to implement or maybe because they > deliberately ignore it.) Or maybe because they are morons who do not read specs and just look at popular content.
> Or maybe because they are morons who do not read specs and just look at popular > content. Insulting implementors and authors because they don't implement or use the spec correctly doesn't change the fact that they didn't implement or use the spec correctly. The more complex the spec, the more implementors and users will make mistakes. It's not a binary "complicated" vs "simple" thing, it's a continuum. Rebindable prefixes as described above are so far on the complicated side of that continuum that it is a mistake to design technologies that use that pattern. I think this should be a blocker issue for any HTMLWG deliverable.
To put this another way: if the target audience contains morons, as you put it, then the design should not assume that its target audience are all brilliant engineers.
I was talking about people who do not read the spec (or any documentation, for that matter), and just wok by trial and error. Anyway, by your statement you do seem to be in conflict with some of our famous design principles. HTML+RDFa content is out there, and there needs to be a spec for it. The XHTML2 WG is (or will be) history, and our *chairs* have invited the RDFa people to publish the HTML+RDFa spec over here. If you're unhappy with that, you really should discuss this directly with the chairs.
(In reply to comment #20) > > The XHTML2 WG is (or will be) history, and our *chairs* have invited the RDFa > people to publish the HTML+RDFa spec over here. If you're unhappy with that, > you really should discuss this directly with the chairs. > We've asked the RDFa Task Force to present an HTML+RDFa spec for review, and we're now calling for consensus to publish it as a First Public Working Draft. We have not asked HTML WG members to hold off on giving feedback on the spec. Indeed, if anyone has issues that would lead them to oppose moving to Last Call in the future, then we would prefer to hear about these issues sooner rather than later. It may be that "big picture" issues like this one cannot easily be resolved, since there may be a direct conflict with compatibility goals. But let's not rule that out up front. It's possible there may be spec changes that would let authors avoid dealing with prefix binding indirection. For example, it could give a list of predefined prefixes, since it seems popular RDFa consumers take this approach anyway, so this would be compatible with deployed content. (I'm not necessarily saying this is the best approach, just an example.)
(In reply to comment #20) > Anyway, by your statement you do seem to be in conflict with some of our famous > design principles. HTML+RDFa content is out there, and there needs to be a spec > for it. What's specified in the draft is very different from how the implementation with the most market significance (Google Rich Snippets) processes existing "RDFa" content. Therefore, the draft has to be considered to be prospective rather than retrospective. A prospective spec that's different enought from the market leader to be considered simultaneously retrospective should have it's design bugs fixed. (If you get rid of prefix-based indirection, one element creating more than one triple and lower the complexity of the model from graph to tree, you get something more similar to microdata than RDFa.)
(In reply to comment #22) > What's specified in the draft is very different from how the implementation > with the most market significance (Google Rich Snippets) processes existing > "RDFa" content. Therefore, the draft has to be considered to be prospective > rather than retrospective. A prospective spec that's different enought from the > market leader to be considered simultaneously retrospective should have it's > design bugs fixed. (If you get rid of prefix-based indirection, one element > creating more than one triple and lower the complexity of the model from graph > to tree, you get something more similar to microdata than RDFa.) So Google is "the market leader" for RDFa processing? And just because they screwed up the spec needs to change?
> I was talking about people who do not read the spec (or any documentation, for > that matter), and just [work] by trial and error. This represents the majority of authors, I believe. This is the target audience for which our deliverables should be designed. It's also the audience most likely to have problems with binding mechanisms that can be separated from the identifiers in the way that the xmlns="" feature (and other proposals like prefixes="") can. > The XHTML2 WG is (or will be) history, and our *chairs* have invited the RDFa > people to publish the HTML+RDFa spec over here. If you're unhappy with that, > you really should discuss this directly with the chairs. I'm following the process the chairs have described that we should follow. I've nothing against RDFa being published, I just have something against RDFa having a rebindable prefix mechanism.
(In reply to comment #23) > So Google is "the market leader" for RDFa processing? Google and Yahoo! are cited by RDFa advocates as notable RDFa consumers. (I gather Drupal is a producer rather than consumer.) Google has more general search market share that Y!, but of course their relative order in market share in "RDFa"-enabled search could be reversed. > And just because they screwed up the spec needs to change? No, not just because of that. However, when Google "will deviate from the standard" on the point of prefix-based indirection, maybe there's something wrong with prefix-based indirection.
(In reply to comment #25) > Google and Yahoo! are cited by RDFa advocates as notable RDFa consumers. (I > gather Drupal is a producer rather than consumer.) Google has more general > search market share that Y!, but of course their relative order in market share > in "RDFa"-enabled search could be reversed. General purpose search engines are just one of many potential consumers. > > And just because they screwed up the spec needs to change? > > No, not just because of that. However, when Google "will deviate from the > standard" on the point of prefix-based indirection, maybe there's something > wrong with prefix-based indirection. That discussion is fresh, let's see where it goes. It appears to me that you're jumping to conclusions, just because the current information seems to support your world-view. Another way to jump to conclusions would be to throw out Microdata and include RDFa -- after all, the "market leader" supports the latter but not the former, right?
(In reply to comment #26) > General purpose search engines are just one of many potential consumers. Sure, but Yahoo! and Google are the names mentioned in order to make the point that RDFa is already big enough that it can't be changed anymore. > Another way to jump to conclusions would be to throw out Microdata and include > RDFa -- after all, the "market leader" supports the latter but not the former, > right? That conclusion would be interesting if Microdata had been available whenever it was the Google started working on Rich Snippets.
Ian's comment can be summarized as "no one has successfully deployed this technology, except for use cases about which I don't care." So, like Shane, I call BS. An objective bug report is one where a clear objective standard for bug-freeness is declared, and that standard is applied fairly to all existing features. What is the standard used here? Ian's personal opinion, however well informed it may be, is not an objective standard. If you look at actual data, here's what you find: Yahoo has published an RDF vocabulary for videos, which Google has chosen to pick up, prefix notation and all, without any coordination from the RDFa Task Force: http://googlewebmastercentral.blogspot.com/2009/09/supporting-facebook-share-and-rdfa-for.html In fact, I suspect there wasn't even any Google/Yahoo coordination on this front. I think even microformats have shown this level of interoperability between two major web players, and microformats have been around years longer than RDFa.
(In reply to comment #28) > If you look at actual data, here's what you find: Yahoo has published an RDF > vocabulary for videos, which Google has chosen to pick up, prefix notation and > all, without any coordination from the RDFa Task Force: > > http://googlewebmastercentral.blogspot.com/2009/09/supporting-facebook-share-and-rdfa-for.html Have you actually tested that Yahoo! and Google process input (conforming and obvious, conforming but non-obvious, non-confoming, etc.) in a uniform way and in a way that resembles compliance to RDFa albeit in the wrong MIME type? The announcement itself doesn't show that two implementors implemented RDFa interoperably and in compliance with the spec.
(In reply to comment #29) > Have you actually tested that Yahoo! and Google process input (conforming and > obvious, conforming but non-obvious, non-confoming, etc.) in a uniform way and > in a way that resembles compliance to RDFa albeit in the wrong MIME type? The > announcement itself doesn't show that two implementors implemented RDFa > interoperably and in compliance with the spec. You're conflating two very different types of users: HTML authors who *write* RDFa, and tool builders who *parse* RDFa. Google and Yahoo, who have historically shown that they care deeply about making things easy for web publishers and users, are both asking HTML authors to take on the "full complexity" of prefixes, both by showing explicit examples of this prefix usage and by referencing the RDFa spec in their explanations. Maybe Google's implementation needs work, as I'm sure Mozilla's does for a number of HTML5 features. But that's hardly relevant to the direction that Google and Yahoo are giving web publishers, and that direction includes prefixes. -Ben
A few nights ago when I first saw this I was slightly upset, my wife asked what was wrong. I ended up bring a pad of paper to bed in order to explain. Nothing like XML/RDF prefixes for pillow talk. I should point out that my wife knows only some HTML and next to nothing about RDF or XML. She does have a degree (German and History, it's important, we'll get back to this), I don't. Anyway, as it turns out it's reasonably easy to write triples on paper using N3 notation. After about 10 minutes my wife was having no trouble understanding how to write statements like "The article about Michelle Obama on The Drudge Report was issued on 2009-09-18." Then on a new page I wrote down a changed a prefix definition! THE HORRORS! dc: now stood for http://www.dccomics.com, "Well, that's not the same dc, so I guess I need to use another prefix for the Dublin thingy." Not that confused then. She pointed out that the citation method for The Chicago Manual of Style used by a wide range of disciplines and a wide range of people is far more complicated. It has features that would horrify the HTML WG. Tokens whose meaning is 100% dependent on scanning backwards for the last instance of another token (ibid), so that while copy editing it's massively important to keep track of them when moving blocks of text around. Shortened person and book names that are document dependent, are the norm. Yet hundreds of thousands of people are able to use this complex citation method. Do people screw it up? All the time. Do they understand why and fix it? Of course. We were able to come up with rules that make using prefixes in almost any context simpler. Note, these are for the most part AUTHORING guidelines, not requirements when reading: * Reusing the same prefix in the same document with different meanings is horribly confusing ("If you did that, I'd break your figures."). Possible to figure out, but not really desirable. Seems like a reasonable place for a warning. * Defining all the prefixes in one place makes it simpler to keep track of them. But understood when it would be simpler to define a new prefix for a section of content. * "Couldn't you have a simple tool that just shows you what prefixes are defined at any point in the document?" How such a tool has failed to exist in the XML world... may write this. I really don't think prefixing as too complicated for wide adoption. Document authors today deal with complex style guides like The Chicago Manual of Style, the Modern Language Association, and APA. All of these are at least as complicated as the notion of prefixing, some more complicated.
Here's a great example of rebindable prefixes being confusing: http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html#msg745 It doesn't even matter who is right and who is wrong in that discussion — the very fact that there can be such a long discussion between some of the most expert people on the subject with such vehement back-and-forth with people telling each other that they are wrong is a clear demonstration of my point.
The confusion in that thread is about what the XHTML+RDFa and HTML+RDFa specs actually say, not the use of prefixes. I dare say such confusion might exist even if the RDFa specs did not use xmlns: attributes or even if they did not use prefix binding at all.
(In reply to comment #32) > Here's a great example of rebindable prefixes being confusing: > http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html#msg745 > > It doesn't even matter who is right and who is wrong in that discussion — the > very fact that there can be such a long discussion between some of the most > expert people on the subject with such vehement back-and-forth with people > telling each other that they are wrong is a clear demonstration of my point. No. You're playing a big role in fomenting this debate, then claiming that the debate you've created justifies the point you're making. That's a little bit circular. Also, the debate is happening between language designers. It's not happening much between users. Users spend 60 seconds learning prefixes, and then they move on to the next thing. We're spending vastly more time debating this than users are learning it. Separate note in response to Gavin: I like your point about not reusing the same prefix twice, this should absolutely be part of a Best Practices document. -Ben
(In reply to comment #34) > (In reply to comment #32) > > Here's a great example of rebindable prefixes being confusing: > > http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html#msg745 > > > > It doesn't even matter who is right and who is wrong in that discussion — the > > very fact that there can be such a long discussion between some of the most > > expert people on the subject with such vehement back-and-forth with people > > telling each other that they are wrong is a clear demonstration of my point. > > No. > > You're playing a big role in fomenting this debate, then claiming that the > debate you've created justifies the point you're making. That's a little bit > circular. For the record, Ian did not participate in that thread or any related discussion. As far as I know, he hasn't discussed it privately with any of the thread participants either. Regardless, I don't think that thread demonstrates author misunderstanding of how prefixes work. > Also, the debate is happening between language designers. It's not happening > much between users. Users spend 60 seconds learning prefixes, and then they > move on to the next thing. We're spending vastly more time debating this than > users are learning it. I do think prefix indirection is somewhat confusing. It seems to be a common error for both producers and consumers of prefix-using data to make the mistake that it's the prefix that is meaningful, rather than the URI it is bound to. Maybe that is an acceptable cost to pay for some benefit. But being dismissive about it does not help to create consensus on this issue.
(In reply to comment #35) > But being dismissive about it does not help to create consensus on this issue. My tone probably reflects that I am a little bit tired of Ian repeatedly bringing up the same subjective issue after evidence has been presented to contradict his POV. That said, I don't think I'm being dismissive. I've presented evidence that tool builders like Google, Yahoo, and others are recommending RDFa, including full prefix notation, to publishers. Since we're arguing about what these publishers will find "too confusing for the Web," we have to look at their actual behavior. The facts point to prefixes being from from "too confusing." (Might prefixes require a little bit of reading up on? Sure. But this bug is about prefixes being "too confusing for the Web." And that's false.) On a separate note, I'm very happy to see that we're starting to discuss consensus building. -Ben
(In reply to comment #35) > (In reply to comment #34) > > (In reply to comment #32) ... snip ... > > Also, the debate is happening between language designers. It's not happening > > much between users. Users spend 60 seconds learning prefixes, and then they > > move on to the next thing. We're spending vastly more time debating this than > > users are learning it. > > I do think prefix indirection is somewhat confusing. It seems to be a common > error for both producers and consumers of prefix-using data to make the mistake > that it's the prefix that is meaningful, rather than the URI it is bound to. Talking about a prefix as not being meaningful doesn't help. Descriptions of prefixes that say "Oh they don't mean anything" are wrong and misleading. A prefix has a very clear meaning in the context of the document or section in which it is defined. Prefixes may change meaning between documents or sections (not a great idea as mentioned) but they have a great deal of meaning. I think a lot of confusion can be reduced by writing better guides on their usage, and explaining them to authors in a less technical method. Anyone who can write or read has to deal with words, phrases, prefixes that change meaning depending on context. I don't see the goal as being to remove all confusion but to reduce it as much as possible.
(In reply to comment #37) > (In reply to comment #35) > > (In reply to comment #34) > > > > I do think prefix indirection is somewhat confusing. It seems to be a common > > error for both producers and consumers of prefix-using data to make the mistake > > that it's the prefix that is meaningful, rather than the URI it is bound to. > > Talking about a prefix as not being meaningful doesn't help. Descriptions of > prefixes that say "Oh they don't mean anything" are wrong and misleading. A > prefix has a very clear meaning in the context of the document or section in > which it is defined. Prefixes may change meaning between documents or sections > (not a great idea as mentioned) but they have a great deal of meaning. To clarify, the error I'm referring to is assuming the exact spelling of the prefix is what's meaningful. For example: it's an error to assume that the exact prefix "foaf:" always indicates the FOAF namespace, and no other prefix does, rather than looking at the prefix mapping.
RDFA-SPEC-SECTIONS [xmlns:-prefixed-attributes]
foo:bar attribute is the same complicated as data-bar attribute from HTML5 etc. It differs one character, once you write ":", once "-". I agree with Shane McCarron.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Partially Accepted Change Description: A number of issues have been added to address this concern in the new RDFa WG: ISSUE-1: http://www.w3.org/2010/02/rdfa/track/issues/1 ISSUE-11: http://www.w3.org/2010/02/rdfa/track/issues/11 ISSUE-14: http://www.w3.org/2010/02/rdfa/track/issues/14 Based on how each of these issues are resolved in the RDFa WG, there will almost certainly be a number of spec changes to RDFa Core 1.1, which would subsequently affect HTML5+RDFa. One of these spec changes would allow prefix-less markup, but with a complete follow-your-nose story. In other words, it would be acceptable both to the die-hard RDF community and the die-hard no-xmlns community. Rationale: This bug is being marked as FIXED, because it has been escalated to an ISSUE in RDFa WG. It's not necessarily resolved yet. We're attempting to partially resolve this bug by FPWD for RDFa 1.1 Core, which will happen in April 2010. We probably should not keep this bug as OPEN, as it seems as if the information is duplicated between this bug and the RDFa WG issue tracker. My understanding is that items should either be tracked here, or in the ISSUE tracker, but not both. I suggest that the submitter of this bug resolve the bug as CLOSED since it has been escalated to an ISSUE item in the RDFa WG tracker.
I'm confused. In what sense is this an RDFa WG issue? I thought it was an issue with the RDFa-in-HTML spec, which is an HTMLWG deliverable, no?
RDFa-in-HTML (aka HTML+RDFa) is built on top of the RDFa in XHTML: Syntax and Processing specification. The RDFa WG will be publishing a RDFa Core 1.1 specification during April 2010 that will become the basis for all future RDFa-based specifications. So that is how this bug is tied with work that the RDFa WG is doing, and that is why the list of issues listed in the Editor's response are of interest to this bug. Here's a proposed timeline for the interplay between RDFa Core 1.1 and HTML+RDFa. * RDFa Core 1.1 FPWD (April 2010) * HTML+RDFa switches it's base document from XHTML+RDFa to RDFa Core 1.1 * RDFa Core 1.1 absorbs some content from HTML+RDFa * HTML+RDFa Heartbeat draft based on RDFa Core 1.1 in (May 2010) * RDFa Core 1.1 LC (October 2010) * HTML+RDFa LC (no sooner than October 2010) We're going for a spec hierarchy that looks like this: +--------- HTML+RDFa | RDFa Core 1.1 ----+--------- SVG+RDFa | +--------- ODF+RDFa So, any changes made to RDFa Core 1.1 will be applied to HTML+RDFa. One of those changes is a prefix-less approach to authoring RDFa. I don't know if that alleviates your concern. Assuming that it doesn't, the next question would be to ask "What would alleviate your concern with prefixes?", to which you've replied in the past "Don't use them at all." If that is still your response, then I'm afraid to say that the RDFa WG will most certainly not be removing support for xmlns: or the general prefixing mechanism. This is doubly so because it has been shown that parsing can be performed in a namespace-aware and non-namespace-aware context. The latest HTML+RDFa draft expresses how to map xmlns: values based on whether or not one is processing in XML-mode or non-XML-mode. This is for several reasons: * It's not realistic to remove support for xmlns: in HTML5. * If the xmlns: attribute continues to exist, it should be expected that web technologies and authors will continue to use it. * There is an installed base for RDFa now, removing the xmlns: feature (which is universally used) from the language is a non-starter for the RDF and RDFa communities. So, with that said, exactly what changes to the specification would you like to see? Please be very clear in your reply - quote sections of the spec, provide exact spec text changes if necessary.
This bug report's description is: "The use of prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of strings is IMHO too complicated for a technology intended for broad Web deployment (e.g. in text/html)." Short of not using prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of strings, I can't see any way to resolve this bug. Therefore if you are not proposing not using prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of strings, then it is my belief that you are rejecting the bug, not partially accepting it. I am, however, always open to novel ideas, so if there is some way to resolve this bug while still using prefixes that can be bound to arbitrary strings then combined with other strings to form a third set of strings, e.g. by making the use of such mechanisms trivially simple and usable in a technology intended for broad Web deployment such as text/html, then that would also satisfy this bug. So far I am not aware of any proposal to do this.
Would any version of RDFa that uses xmlns: be acceptable to you? I presume that your answer is going to be "No". If so, I'll set the editor's response to REJECTED and you will have to escalate this to an HTML WG ISSUE.
(In reply to comment #45) > Would any version of RDFa that uses xmlns: be acceptable to you? Ian, I need a response on this - would any version of RDFa that uses xmlns: be acceptable to you? Also, could you answer this question: Would any version of RDFa that uses a prefixes that can be bound to arbitrary URLs then combined with other strings to form a URL be acceptable to you. I believe that this is still your position, but would like to hear it again from you (because your position may have changed since this bug was created).
> Would any version of RDFa that uses xmlns: be acceptable to you? I don't know what you mean by "xmlns:" here. If you mean in the same way that HTML5 currently "uses" xmlns, namely as a set of optional attributes with fixed values that have no effect on the processing model, then yes, that would be fine. > Also, could you answer this question: > > Would any version of RDFa that uses a prefixes that can be bound to arbitrary > URLs then combined with other strings to form a URL be acceptable to you. I'm not aware of any proposal that does the above that I consider simple enough for broad Web deployment, but that doesn't mean one doesn't exist. I do not wish to be obtuse; nor is this bug intended to be an obstinate roadblock. I truly am open to other ideas, I just think that, as described in the original bug description and in comment 44, the current mechanism is too complicated.
(In reply to comment #47) > > Would any version of RDFa that uses a prefixes that can be bound to arbitrary > > URLs then combined with other strings to form a URL be acceptable to you. > > I'm not aware of any proposal that does the above that I consider simple enough > for broad Web deployment, but that doesn't mean one doesn't exist. I do not > wish to be obtuse; nor is this bug intended to be an obstinate roadblock. I > truly am open to other ideas, I just think that, as described in the original > bug description and in comment 44, the current mechanism is too complicated. Just for the record: "too complicated" is subjective; there are many people who don't think at all this is too complicated. That being said: it is one level of indirection, and I don't believe that replacing it with a different-looking but similar level of indirection would be helpful; it just would cause more confusion. As far as I understand, RDFa is going to allow URIs where previously CURIEs were required. So it would be *possible* to write RDFa without this kind of indirections. Why not just recommend that notation to authors who can't deal with prefixes?
Because authors will still have to maintain the markup written by people who didn't think it was complicated (and probably got it very wrong, making the new author's job even harder).
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected removal of CURIEs from RDFa Core 1.1 and HTML+RDFa 1.1 Change Description: Changes have been made in RDFa Core 1.1 and HTML+RDFa 1.1 to enable CURIE-less usage of RDFa. Full-IRIs in RDFa attributes: http://www.w3.org/TR/rdfa-core/#s_curieprocessing and RDFa Profiles: http://www.w3.org/TR/rdfa-core/#s_profiles are two of the mechanisms now available in RDFa Core 1.1 that don't require the use of CURIEs. Rationale: Removal of CURIEs from RDFa Core 1.1 is not something that the RDFa WG is willing to do, especially since there is broad deployment for CURIEs at the moment. If you wish to pursue this further, please raise this as an ISSUE in the HTML WG.
Ian, since you added TrackerRequest, could you provide a suggested title and description for the issue?
http://www.w3.org/html/wg/tracker/issues/120
mass-move component to LC1