Re: ISSUE-1: Status of RDFa Profiles

On 03/16/2010 07:47 PM, Ben Adida wrote:
>> The other problem is that it introduces a conflict with full URIs in
>> attributes.
>>
>> e.g.
>>
>>     <div profile="http://example.com/vocab">
>>         <span property="foo:bar">foo bar</span>
>>     </div>
>>
>> If example.com is down, the parser has no way of determining whether
>> "foo" is a CURIE prefix defined by the profile, or a URI scheme.

Yes, that's true - but what's the damage caused as a result of the
profile being down? A bad triple?

I know we were very concerned about polluting the default graph in RDFa
1.0, but lately I've wondered if the trade-off of rejecting powerful
features in the off chance that they may produce invalid triples is a
good thing. So, in this case, perhaps we generate the following triple:

<>
   <foo:bar>
      "foo bar" .

Yes, it's a junk triple - but do we think that anybody is going to
trigger off of that triple?

We may even want to consider an RDFa Processor Exception event that is
fired when a profile document cannot be dereferenced. The application
can choose to ignore the exception or continue processing - this would
ensure that the application knows if it can trust triples that are being
generated or not. In other words, I think we can mitigate this issue
quite easily through a simple exception mechanism.

> Mark's token proposal is very elegant, but I don't see how it matches
> the constraints of RDFa 1.0, and I'm pretty sure most HTML authors won't
> see the parallel: it's one level of abstraction/indirection too much.

I think the key point is that most HTML authors won't care about the
abstraction/indirection. They're just going to plug the @profile in and
follow the documentation on the Google/FOAF/DublinCore website.

The less there is to "get" about RDFa, the better off we are - and if we
can reduce two concepts that people need to be aware of
(prefixes/keywords, how they're defined and when you can use them) into
one concept (mappings) that nobody has to learn if they're using
@profile... then I think we come out ahead as far as web author ease is
concerned.

> Mark, you say that you want to eliminate @xmlns... but we can't. Parsers
> are going to continue to support it, and people will mix RDFa 1.0 and
> 1.1 conventions for a very long time.

I don't think Mark ever said he wanted to eliminate @xmlns - I don't
think anybody thinks that. Mark and I do think that RDFa is better off
without it, for the simple markup cases.

If some don't agree with that philosophy, they're free to use @xmlns...
for as long as it'll be around.

Many on here may not be aware that this parallels a discussion currently
going on in HTML WG that completely deprecates xmlns in HTML5 for
distributed extensibility. I think that arguing for @xmlns is a losing
battle at this point regarding distributed extensibility. Here's the
CSS-like mechanism that's probably going to replace it[1]:

<x-foo-element x-foo="bar">
   ...
</x-foo-element>

> Ivan, you say that @profile in the BODY is not RDFa 1.0 compliant. True,
> but we already have to deal with non-compliant HTML all the time (extra
> attributes for various JavaScript toolkits, etc...), so we *know* that,
> as people deploy RDFa 1.1 markup, RDFa 1.0 parsers will pick it up and
> generate triples. We need to ensure that those triples are a subset of
> the RDFa 1.1 triples.

Yes, we certainly do care very much about backwards compatibility... but
we should only care about old software for so long. There are two
directions to look at this from:

1) Does a RDFa 1.1 processor, when applied to a RDFa 1.0 document,
   produce the same RDFa 1.0 triples (and then some)?
2) Does a RDFa 1.0 processor, when applied to a RDFa 1.1 document,
   produce the same RDFa 1.0 triples?

The answer to #1 with all of the current proposals is yes, most definitely.

The answer to #2 is no for corner-cases - in cases where one mixes
@profile into the body of the document.

Keep in mind that #2 is invalid markup in XHTML+RDFa1.0. People will do
it, regardless... but if they get the wrong triples they are a) using an
out-dated RDFa 1.0 Processor and, simultaneously, b) using invalid
XHTML+RDFa 1.0 markup.

There are a number of ways to mitigate this outcome:

1) Immediately deprecate XHTML+RDFa 1.0 when XHTML+RDFa 1.1 comes out,
   let the entire community know that they should upgrade as soon as
   possible to RDFa 1.1.
2) Ensure that Google and Yahoo know that they should upgrade to the
   latest RDFa 1.1 Processing Rules.
3) Tell Vocabulary developers and Profile developers to /NOT/ declare
   prefixes for older vocabularies such as Dublin Core, FOAF, VCard,
   etc. until a year or more after RDFa 1.1 is adopted by the major
   search companies and browser vendors.
4) Tell authors to be careful if they mix xmlns: and @profile in the
   same document.

> So, again, I come back to this point: conceptually, no matter how we
> express @profile's, I don't see how we can let them import prefixes
> without causing significant problems.

I'm not convinced that the problems are significant enough to prevent
the importing of prefixes based on the reasoning above. Perhaps you
still see this as a significant deterrent for importing prefixes, and if
so, why would the argumentation/strategies above not be acceptable to you?

-- manu

[1]http://lists.w3.org/Archives/Public/public-html/2010Mar/0365.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarming Goes Open Source
http://blog.digitalbazaar.com/2010/02/01/bitmunk-payswarming/

Received on Wednesday, 17 March 2010 02:54:50 UTC