This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 22741 - validator.w3.org does not give an option to validate HTML+RDFa
Summary: validator.w3.org does not give an option to validate HTML+RDFa
Status: RESOLVED FIXED
Alias: None
Product: HTML Checker
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: P2 normal
Target Milestone: ---
Assignee: Michael[tm] Smith
QA Contact: qa-dev tracking
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-20 15:40 UTC by Shane McCarron
Modified: 2015-08-23 07:07 UTC (History)
4 users (show)

See Also:


Attachments

Description Shane McCarron 2013-07-20 15:40:11 UTC
HTML+RDFa is a W3C Proposed Recommendation, and it is currently in use in a number of specifications under development with the permission of the publication folks.  ReSpec automatically generates HTML+RDFa (or XHTML+RDFa).  Unfortunately, the validator complains about RDFa in documents, seemingly because it is enforcing the RDFa Lite restrictions on the documents.  This is causing some consternation in the W3C spec development community.

There should be an option to validate using HTML+RDFa, not just HTML+RDFa Lite.  And this option should be the default, at least when checking from 'pubrules' because RDFa Lite is inadequate for the semantic markup that is being embedded in W3C specifications.
Comment 1 Michael[tm] Smith 2013-07-21 03:28:36 UTC
(In reply to comment #0)
> HTML+RDFa is a W3C Proposed Recommendation, and it is currently in use in a
> number of specifications under development with the permission of the
> publication folks.  ReSpec automatically generates HTML+RDFa (or
> XHTML+RDFa).

It's imaginable that ReSpec could provide an option for generating RDFa Lite as well.

> Unfortunately, the validator complains about RDFa in
> documents, seemingly because it is enforcing the RDFa Lite restrictions on
> the documents.  This is causing some consternation in the W3C spec
> development community.

Whatever such consternation there might be, it should be weighed against the needs of the wider community of validator users. I don't think any of us would want the validator optimized for the needs of the W3C spec-development community to the possible detriment of the needs of the wider community. And I don't think at this point in the wider community of validator users there's significant consternation about RDFa Lite being the default.

> There should be an option to validate using HTML+RDFa, not just HTML+RDFa
> Lite.

There is a such an option at http://validator.w3.org/nu -- which is the service that this bug was filed against (Product: Validator, Component: HTML5).

> And this option should be the default, at least when checking from
> 'pubrules'

Yes, it could be made the default for W3C pubrules users without it needing to be made the default for all other users as well.

> because RDFa Lite is inadequate for the semantic markup that is
> being embedded in W3C specifications.

I don't think there's yet any actual consensus in the W3C spec-development community about that being the case. I'd think before that statement was just accepted as true, there'd need to be a lot more discussion about it in the W3C spec-development community (e.g., on the spec-prod mailing list or somewhere).
Comment 2 Shane McCarron 2013-07-21 14:17:35 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > HTML+RDFa is a W3C Proposed Recommendation, and it is currently in use in a
> > number of specifications under development with the permission of the
> > publication folks.  ReSpec automatically generates HTML+RDFa (or
> > XHTML+RDFa).
> 
> It's imaginable that ReSpec could provide an option for generating RDFa Lite
> as well.
>

Not very easily, and not with the correct semantics.  Moreover, since all RDFa Processors are required to process ALL of RDFa, there is no technical reason to hamstring the content like that.
 
> > Unfortunately, the validator complains about RDFa in
> > documents, seemingly because it is enforcing the RDFa Lite restrictions on
> > the documents.  This is causing some consternation in the W3C spec
> > development community.
> 
> Whatever such consternation there might be, it should be weighed against the
> needs of the wider community of validator users. I don't think any of us
> would want the validator optimized for the needs of the W3C spec-development
> community to the possible detriment of the needs of the wider community. And
> I don't think at this point in the wider community of validator users
> there's significant consternation about RDFa Lite being the default.

I don't have any way to gauge that, but I agree that the validator is pointed at a much wider community than just W3C specification authors.  To that end, I am not sure I would have it include any sort of RDFa as a default.  Of course, since HTML has no built-in announcement mechanism to help the validator understand what collection of optional HTML extensions are in use, that would make it even more inconvenient for the casual user.

> 
> > There should be an option to validate using HTML+RDFa, not just HTML+RDFa
> > Lite.
> 
> There is a such an option at http://validator.w3.org/nu -- which is the
> service that this bug was filed against (Product: Validator, Component:
> HTML5).

I agree that there is such an option.

> 
> > And this option should be the default, at least when checking from
> > 'pubrules'
> 
> Yes, it could be made the default for W3C pubrules users without it needing
> to be made the default for all other users as well.

I don't know how those things are connected.  If pubrules did that, and also if there were a way to set my personal preferences via a cookie or something so it would remember what variant I wanted each time I accessed it independently, that would be a real help.

> 
> > because RDFa Lite is inadequate for the semantic markup that is
> > being embedded in W3C specifications.
> 
> I don't think there's yet any actual consensus in the W3C spec-development
> community about that being the case. I'd think before that statement was
> just accepted as true, there'd need to be a lot more discussion about it in
> the W3C spec-development community (e.g., on the spec-prod mailing list or
> somewhere).

Well..  hmm.  There are not very many people in this community, and of them there are hardly any that know enough about RDFa and the desired document semantics to have an opinion.  I will see if I can get a few of them to comment on this thread.

Thanks for your attention.
Comment 3 Gregg Kellogg 2013-07-21 16:18:59 UTC
It's true that much of the ReSpec output could be rewritten in plain RDFa Lite, but not the critical ordering of authors and editors; this requires using the @inlist attribute.

It seems rather arbitrary to naturally validate RDFa 1.1 Lite, and call other RDFa content invalid. This perpetuates the notion that one is "better" than the other, which just isn't the case. Ideally, when seeing an RDFa 1.1 attribute, or combination of attributes, the validator could automatically switch to 1.1 mode, or at least signal that the content might be valid RDFa 1.1 and make it easy to redirect to the proper validator mode.
Comment 4 Manu Sporny 2013-07-21 16:49:52 UTC
Additionally, I keep getting comments from people that claim that the W3C Validator is broken because their RDFa markup doesn't validate. In many cases, their markup is valid, but since the validator uses RDFa Lite 1.1 by default, it makes it seem like their markup is broken when it isn't.

There are a few solutions that I can think of to this problem:

Make RDFa 1.1 the default, and if the document validates as RDFa 1.1, put a button on the page that states that they can click to also validate the document as RDFa 1.1 Lite.

Keep RDFa Lite 1.1 as the default, but if the validation fails, try RDFa 1.1 and if it succeeds, make a note of it passing as RDFa 1.1. Maybe say that the document failed as RDFa Lite 1.1, but passes as regular RDFa 1.1 and show the normal success page.

I'm starting to think that this as a pretty bad usability issue with the validator. Putting aside the computing resources necessary to run the validator multiple times, given the target audience, the validator should just "do the right thing" in these instances where there is a clear algorithm for checking to see if the document is valid or not.
Comment 5 scor 2013-07-22 13:04:05 UTC
This is a usability issue that I've heard many people complain about when trying to validate their site. Drupal 7 outputs regular RDFa, not RDFa Lite which was published a few years after Drupal 7 release. That means that the 658,905 sites [1] running Drupal 7 (the majority of which have RDFa enabled) will get errors when they try to validate, although their markup is valid RDFa. Drupal 7 will be around for many years to come, and we can only expect the number above to increase. If nothing is done about this validation usability problem, we will also see the number of bug report like this [2] increase too.

I'm also aware of projects who are worried about switching from RDFa Lite to RDFa full just because it's not "RDFa Lite" and the validator will complain. Asking people to manually switch to a different preset is not a solution.

RDFa Lite is only a starter level for RDFa, there is nothing wrong with needing to upgrade to RDFa full, and people choosing RDFa full should not be penalized. That's unfair.

Steph.

[1] https://drupal.org/project/usage/drupal
[2] https://drupal.org/node/1633802
Comment 6 scor 2013-07-22 13:07:01 UTC
It should also be noted that the RDFa Full preset was the default preset for a few weeks, I distinctly remember seeing it and trying it out... until June 26th when RDFa Lite was made default again. Can we get it back?

Steph.

[1] https://bitbucket.org/validator/validator/commits/bc6aa024c448560cb247a30da4a9d2182d92bac5
Comment 7 Michael[tm] Smith 2013-08-07 17:13:04 UTC
OK the production validator now includes RFA 1.1 Core checking by default. There is no longer an option for RDFa 1.1 Lite checking at all -- because it's not clear to me there are real-world users in the wider community who want a separate Lite-checking option. So I don't think we should  re-add a Lite option unless we end up seeing clear demand for it from the community.