HTML+RDFa Issues (update)

[Manu Sporny]

We had a fairly productive discussion last week (draft minutes[1])
regarding the most pressing issues surrounding HTML+RDFa. A brief
summary of the findings can be found here:

http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order

Regrets for the call tomorrow, I won't have Internet access.

Some quick thoughts on the next set of issues:

== Processing of xmlns:* in non-XML languages ==

I think that we should phase out xmlns:* for the following reasons:

 * There is a case-sensitivity issue when used in HTML4 markup.
 * It's technically feasible, but has led to a number of
   namespace rants and "polluting HTML4/5 with namespaces" rants.

We could replace xmlns:* with @prefix or Mark's upcoming @token
proposal. xmlns:* should exist for backwards compatibility, but we could
suggest that it may be phased out in future versions of RDFa and should
not be used for new markup.

== Case sensitivity for xmlns: attributes and prefixes in attribute
   values ==

As Shane has mentioned previously, we should immediately update the
XHTML+RDFa errata document to say that all prefixes specified by xmlns:
should be lower-case. In other words, authors SHOULD NOT use mixed case
for prefixes. Therefore, doing the following would be frowned upon:

xmlns:Foo or xmlns:FooBar or xmlns:FOOBAR

the suggested markup should be:

xmlns:foo or xmlns:foobar or xmlns:foobar

I agree with Shane's assessment: I don't think we need to change the
parsing rules to lower-case prefix names in xmlns:. We should provide
guidance to authors so that if they want to create markup that works in
both HTML and XHTML, they should not mix case if xmlns: is used.

This point isn't moot if we transition away from using xmlns:* - we will
still need to provide guidance for those that continue to use xmlns:* in
XHTML1.1 documents.

= Use of regular CURIEs in @rel =

I believe that Julian Reschke has raised this issue several times. I
don't remember the technical issue and I remember Ben stating clearly
that there isn't a technical issue.

I don't have any input on this at the present time. Clearly, if a
technical issue exists with CURIEs in @rel - we must address it.

= Script-based modification of DOM =

If we include language to address this issue in an XYZ+RDFa document,
the language should be minimal.

The only time that RDFa enters the picture is when the
(X)HTML/Javascript model/control layer serializes/streams the (X)HTML
document into/to a tree model and hands it off to the RDFa parser. The
RDFa parser shouldn't have any knowledge of how the tree model is
generated - but we shouldn't be strict about making this point.

Re-parsing can be done whenever a DOM changed happens, on a X second
timeout basis, or at the leisure of the browser - for example, when CPU
usage is low.

If this is a question of /when/ the RDFa parser should be called, our
answer should be "whenever the application layer wants to run the RDFa
parser".

If this is a question of /how/ the RDFa parser should be called, we
shouldn't go to great lengths to specify how that is done. For example,
if speed optimizations for incremental DOM parsing of an HTML document
(versus complete parsing of the HTML document) are desired - the
implementation is up to the implementer of the incremental RDFa parser
(which would need specific hooks into the DOM layer and vice versa).

The important part is that the triples that are generated via an
incremental RDFa parser should be exactly the same as if the document
was parsed fully. I don't think we need to specify much more than that.

-- manu

[1] http://www.w3.org/2009/06/25-rdfa-minutes.html

--
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

[Ben Adida-2]

Hi folks,

I thought I'd be able to make it to the call this week, but last minute
stuff before a short 4th of july trip are making it impossible, so
regrets from me.

I'll write some thoughts on Manu's points below after the (US) holiday
weekend :)

-Ben

Manu Sporny wrote:

> We had a fairly productive discussion last week (draft minutes[1])
> regarding the most pressing issues surrounding HTML+RDFa. A brief
> summary of the findings can be found here:
>
> http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order
>
> Regrets for the call tomorrow, I won't have Internet access.
>
> Some quick thoughts on the next set of issues:
>
> == Processing of xmlns:* in non-XML languages ==
>
> I think that we should phase out xmlns:* for the following reasons:
>
>  * There is a case-sensitivity issue when used in HTML4 markup.
>  * It's technically feasible, but has led to a number of
>    namespace rants and "polluting HTML4/5 with namespaces" rants.
>
> We could replace xmlns:* with @prefix or Mark's upcoming @token
> proposal. xmlns:* should exist for backwards compatibility, but we could
> suggest that it may be phased out in future versions of RDFa and should
> not be used for new markup.
>
> == Case sensitivity for xmlns: attributes and prefixes in attribute
>    values ==
>
> As Shane has mentioned previously, we should immediately update the
> XHTML+RDFa errata document to say that all prefixes specified by xmlns:
> should be lower-case. In other words, authors SHOULD NOT use mixed case
> for prefixes. Therefore, doing the following would be frowned upon:
>
> xmlns:Foo or xmlns:FooBar or xmlns:FOOBAR
>
> the suggested markup should be:
>
> xmlns:foo or xmlns:foobar or xmlns:foobar
>
> I agree with Shane's assessment: I don't think we need to change the
> parsing rules to lower-case prefix names in xmlns:. We should provide
> guidance to authors so that if they want to create markup that works in
> both HTML and XHTML, they should not mix case if xmlns: is used.
>
> This point isn't moot if we transition away from using xmlns:* - we will
> still need to provide guidance for those that continue to use xmlns:* in
> XHTML1.1 documents.
>
> = Use of regular CURIEs in @rel =
>
> I believe that Julian Reschke has raised this issue several times. I
> don't remember the technical issue and I remember Ben stating clearly
> that there isn't a technical issue.
>
> I don't have any input on this at the present time. Clearly, if a
> technical issue exists with CURIEs in @rel - we must address it.
>
> = Script-based modification of DOM =
>
> If we include language to address this issue in an XYZ+RDFa document,
> the language should be minimal.
>
> The only time that RDFa enters the picture is when the
> (X)HTML/Javascript model/control layer serializes/streams the (X)HTML
> document into/to a tree model and hands it off to the RDFa parser. The
> RDFa parser shouldn't have any knowledge of how the tree model is
> generated - but we shouldn't be strict about making this point.
>
> Re-parsing can be done whenever a DOM changed happens, on a X second
> timeout basis, or at the leisure of the browser - for example, when CPU
> usage is low.
>
> If this is a question of /when/ the RDFa parser should be called, our
> answer should be "whenever the application layer wants to run the RDFa
> parser".
>
> If this is a question of /how/ the RDFa parser should be called, we
> shouldn't go to great lengths to specify how that is done. For example,
> if speed optimizations for incremental DOM parsing of an HTML document
> (versus complete parsing of the HTML document) are desired - the
> implementation is up to the implementer of the incremental RDFa parser
> (which would need specific hooks into the DOM layer and vice versa).
>
> The important part is that the triples that are generated via an
> incremental RDFa parser should be exactly the same as if the document
> was parsed fully. I don't think we need to specify much more than that.
>
> -- manu
>
> [1] http://www.w3.org/2009/06/25-rdfa-minutes.html
>

[Toby Inkster-4]

On 2 Jul 2009, at 05:00, Manu Sporny wrote:

> As Shane has mentioned previously, we should immediately update the
> XHTML+RDFa errata document to say that all prefixes specified by  
> xmlns:
> should be lower-case. In other words, authors SHOULD NOT use mixed  
> case
> for prefixes.


I think even that's too strong a prohibition!

How about: authors SHOULD NOT define two CURIE prefixes which differ  
only by case.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Steven Pemberton-3]

On Thu, 02 Jul 2009 10:01:09 +0200, Toby A Inkster <tai@...> wrote:

> On 2 Jul 2009, at 05:00, Manu Sporny wrote:
>
>> As Shane has mentioned previously, we should immediately update the
>> XHTML+RDFa errata document to say that all prefixes specified by xmlns:
>> should be lower-case. In other words, authors SHOULD NOT use mixed case
>> for prefixes.
>
>
> I think even that's too strong a prohibition!
>
> How about: authors SHOULD NOT define two CURIE prefixes which differ  
> only by case.
>

+1 to that.

Steven

[Mark Birbeck-4]

To those that are left, is there any point in having a call? I'm not
sure there is much we can do.


Regards,

Mark

On Thu, Jul 2, 2009 at 7:19 AM, Ben Adida<ben@...> wrote:

>
> Hi folks,
>
> I thought I'd be able to make it to the call this week, but last minute
> stuff before a short 4th of july trip are making it impossible, so
> regrets from me.
>
> I'll write some thoughts on Manu's points below after the (US) holiday
> weekend :)
>
> -Ben
>
> Manu Sporny wrote:
>> We had a fairly productive discussion last week (draft minutes[1])
>> regarding the most pressing issues surrounding HTML+RDFa. A brief
>> summary of the findings can be found here:
>>
>> http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order
>>
>> Regrets for the call tomorrow, I won't have Internet access.
>>
>> Some quick thoughts on the next set of issues:
>>
>> == Processing of xmlns:* in non-XML languages ==
>>
>> I think that we should phase out xmlns:* for the following reasons:
>>
>>  * There is a case-sensitivity issue when used in HTML4 markup.
>>  * It's technically feasible, but has led to a number of
>>    namespace rants and "polluting HTML4/5 with namespaces" rants.
>>
>> We could replace xmlns:* with @prefix or Mark's upcoming @token
>> proposal. xmlns:* should exist for backwards compatibility, but we could
>> suggest that it may be phased out in future versions of RDFa and should
>> not be used for new markup.
>>
>> == Case sensitivity for xmlns: attributes and prefixes in attribute
>>    values ==
>>
>> As Shane has mentioned previously, we should immediately update the
>> XHTML+RDFa errata document to say that all prefixes specified by xmlns:
>> should be lower-case. In other words, authors SHOULD NOT use mixed case
>> for prefixes. Therefore, doing the following would be frowned upon:
>>
>> xmlns:Foo or xmlns:FooBar or xmlns:FOOBAR
>>
>> the suggested markup should be:
>>
>> xmlns:foo or xmlns:foobar or xmlns:foobar
>>
>> I agree with Shane's assessment: I don't think we need to change the
>> parsing rules to lower-case prefix names in xmlns:. We should provide
>> guidance to authors so that if they want to create markup that works in
>> both HTML and XHTML, they should not mix case if xmlns: is used.
>>
>> This point isn't moot if we transition away from using xmlns:* - we will
>> still need to provide guidance for those that continue to use xmlns:* in
>> XHTML1.1 documents.
>>
>> = Use of regular CURIEs in @rel =
>>
>> I believe that Julian Reschke has raised this issue several times. I
>> don't remember the technical issue and I remember Ben stating clearly
>> that there isn't a technical issue.
>>
>> I don't have any input on this at the present time. Clearly, if a
>> technical issue exists with CURIEs in @rel - we must address it.
>>
>> = Script-based modification of DOM =
>>
>> If we include language to address this issue in an XYZ+RDFa document,
>> the language should be minimal.
>>
>> The only time that RDFa enters the picture is when the
>> (X)HTML/Javascript model/control layer serializes/streams the (X)HTML
>> document into/to a tree model and hands it off to the RDFa parser. The
>> RDFa parser shouldn't have any knowledge of how the tree model is
>> generated - but we shouldn't be strict about making this point.
>>
>> Re-parsing can be done whenever a DOM changed happens, on a X second
>> timeout basis, or at the leisure of the browser - for example, when CPU
>> usage is low.
>>
>> If this is a question of /when/ the RDFa parser should be called, our
>> answer should be "whenever the application layer wants to run the RDFa
>> parser".
>>
>> If this is a question of /how/ the RDFa parser should be called, we
>> shouldn't go to great lengths to specify how that is done. For example,
>> if speed optimizations for incremental DOM parsing of an HTML document
>> (versus complete parsing of the HTML document) are desired - the
>> implementation is up to the implementer of the incremental RDFa parser
>> (which would need specific hooks into the DOM layer and vice versa).
>>
>> The important part is that the triples that are generated via an
>> incremental RDFa parser should be exactly the same as if the document
>> was parsed fully. I don't think we need to specify much more than that.
>>
>> -- manu
>>
>> [1] http://www.w3.org/2009/06/25-rdfa-minutes.html
>>
>
>
>

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[Steven Pemberton-3]

Agree, cancel.

Nice quote from Guus Schreiber about RDFa that you tweeted by the way Mark.

Steven

On Thu, 02 Jul 2009 16:48:30 +0200, Mark Birbeck  
<mark.birbeck@...> wrote:

> To those that are left, is there any point in having a call? I'm not
> sure there is much we can do.
>
>
> Regards,
>
> Mark
>
> On Thu, Jul 2, 2009 at 7:19 AM, Ben Adida<ben@...> wrote:
>>
>> Hi folks,
>>
>> I thought I'd be able to make it to the call this week, but last minute
>> stuff before a short 4th of july trip are making it impossible, so
>> regrets from me.
>>
>> I'll write some thoughts on Manu's points below after the (US) holiday
>> weekend :)
>>
>> -Ben
>>
>> Manu Sporny wrote:
>>> We had a fairly productive discussion last week (draft minutes[1])
>>> regarding the most pressing issues surrounding HTML+RDFa. A brief
>>> summary of the findings can be found here:
>>>
>>> http://rdfa.info/wiki/rdfa-in-html-issues#RDFa_Task_Force_Discussion_Order
>>>
>>> Regrets for the call tomorrow, I won't have Internet access.
>>>
>>> Some quick thoughts on the next set of issues:
>>>
>>> == Processing of xmlns:* in non-XML languages ==
>>>
>>> I think that we should phase out xmlns:* for the following reasons:
>>>
>>>  * There is a case-sensitivity issue when used in HTML4 markup.
>>>  * It's technically feasible, but has led to a number of
>>>    namespace rants and "polluting HTML4/5 with namespaces" rants.
>>>
>>> We could replace xmlns:* with @prefix or Mark's upcoming @token
>>> proposal. xmlns:* should exist for backwards compatibility, but we  
>>> could
>>> suggest that it may be phased out in future versions of RDFa and should
>>> not be used for new markup.
>>>
>>> == Case sensitivity for xmlns: attributes and prefixes in attribute
>>>    values ==
>>>
>>> As Shane has mentioned previously, we should immediately update the
>>> XHTML+RDFa errata document to say that all prefixes specified by xmlns:
>>> should be lower-case. In other words, authors SHOULD NOT use mixed case
>>> for prefixes. Therefore, doing the following would be frowned upon:
>>>
>>> xmlns:Foo or xmlns:FooBar or xmlns:FOOBAR
>>>
>>> the suggested markup should be:
>>>
>>> xmlns:foo or xmlns:foobar or xmlns:foobar
>>>
>>> I agree with Shane's assessment: I don't think we need to change the
>>> parsing rules to lower-case prefix names in xmlns:. We should provide
>>> guidance to authors so that if they want to create markup that works in
>>> both HTML and XHTML, they should not mix case if xmlns: is used.
>>>
>>> This point isn't moot if we transition away from using xmlns:* - we  
>>> will
>>> still need to provide guidance for those that continue to use xmlns:*  
>>> in
>>> XHTML1.1 documents.
>>>
>>> = Use of regular CURIEs in @rel =
>>>
>>> I believe that Julian Reschke has raised this issue several times. I
>>> don't remember the technical issue and I remember Ben stating clearly
>>> that there isn't a technical issue.
>>>
>>> I don't have any input on this at the present time. Clearly, if a
>>> technical issue exists with CURIEs in @rel - we must address it.
>>>
>>> = Script-based modification of DOM =
>>>
>>> If we include language to address this issue in an XYZ+RDFa document,
>>> the language should be minimal.
>>>
>>> The only time that RDFa enters the picture is when the
>>> (X)HTML/Javascript model/control layer serializes/streams the (X)HTML
>>> document into/to a tree model and hands it off to the RDFa parser. The
>>> RDFa parser shouldn't have any knowledge of how the tree model is
>>> generated - but we shouldn't be strict about making this point.
>>>
>>> Re-parsing can be done whenever a DOM changed happens, on a X second
>>> timeout basis, or at the leisure of the browser - for example, when CPU
>>> usage is low.
>>>
>>> If this is a question of /when/ the RDFa parser should be called, our
>>> answer should be "whenever the application layer wants to run the RDFa
>>> parser".
>>>
>>> If this is a question of /how/ the RDFa parser should be called, we
>>> shouldn't go to great lengths to specify how that is done. For example,
>>> if speed optimizations for incremental DOM parsing of an HTML document
>>> (versus complete parsing of the HTML document) are desired - the
>>> implementation is up to the implementer of the incremental RDFa parser
>>> (which would need specific hooks into the DOM layer and vice versa).
>>>
>>> The important part is that the triples that are generated via an
>>> incremental RDFa parser should be exactly the same as if the document
>>> was parsed fully. I don't think we need to specify much more than that.
>>>
>>> -- manu
>>>
>>> [1] http://www.w3.org/2009/06/25-rdfa-minutes.html
>>>
>>
>>
>>
>
>
>

[Mark Birbeck-4]

Hi Steven,

> Agree, cancel.

Great...I could use the time.


> Nice quote from Guus Schreiber about RDFa that you tweeted by the way Mark.

I almost replied 'but it's not too late' (for a European body to give
RDFa some money).

;)

All the best,

Mark

--
Mark Birbeck, webBackplane

mark.birbeck@...

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

[rubys]

Manu Sporny wrote:
>
> = Use of regular CURIEs in @rel =
>
> I believe that Julian Reschke has raised this issue several times. I
> don't remember the technical issue and I remember Ben stating clearly
> that there isn't a technical issue.
>
> I don't have any input on this at the present time. Clearly, if a
> technical issue exists with CURIEs in @rel - we must address it.

If I remember correctly, the issue that Julian raised is that a number
of potential "consumers" have created multiple, potentially incompatible
ways of interpreting the value of the rel attribute.  Some may interpret
it as a list of tokens, some as a list of URIs, and some as a list of
CURIEs.

The technical issue is that it is theoretically possible to construct a
rel value which has a list of URIs which could be accidentally
interpreted as a list of CURIEs.  Consider the following:

<a xmlns:urn="http://purl.org/dc/terms/"
    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
    href="http://example.com/terms_of_service.html" >

My take: while it is possible to construct such examples, in practice
they would be rare enough to not be an issue.  That being said, it is
nearly impossible to legislate against, as it would require people to
avoid declaring namespaces prefix that matches any current or future URI
scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be in order.

- Sam Ruby

[Shane McCarron]

Sam Ruby wrote:
> My take: while it is possible to construct such examples, in practice
> they would be rare enough to not be an issue.  That being said, it is
> nearly impossible to legislate against, as it would require people to
> avoid declaring namespaces prefix that matches any current or future
> URI scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be
> in order.
I like this.  In fact, I am sure we used to have text like that.  Not
sure why it was removed, but +1 from me!


--
Shane P. McCarron                          Phone: [phone] x120
Managing Director                            Fax: [phone]
ApTest Minnesota                            Inet: shane@...

[Julian Reschke]

Sam Ruby wrote:

> Manu Sporny wrote:
>>
>> = Use of regular CURIEs in @rel =
>>
>> I believe that Julian Reschke has raised this issue several times. I
>> don't remember the technical issue and I remember Ben stating clearly
>> that there isn't a technical issue.
>>
>> I don't have any input on this at the present time. Clearly, if a
>> technical issue exists with CURIEs in @rel - we must address it.
>
> If I remember correctly, the issue that Julian raised is that a number
> of potential "consumers" have created multiple, potentially incompatible
> ways of interpreting the value of the rel attribute.  Some may interpret
> it as a list of tokens, some as a list of URIs, and some as a list of
> CURIEs.

Indeed. Note that the two interpretations are somewhat compatible, while
the CURIE interpretation is not.

> The technical issue is that it is theoretically possible to construct a
> rel value which has a list of URIs which could be accidentally
> interpreted as a list of CURIEs.  Consider the following:
>
> <a xmlns:urn="http://purl.org/dc/terms/"
>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>    href="http://example.com/terms_of_service.html" >
>
> My take: while it is possible to construct such examples, in practice
> they would be rare enough to not be an issue.  That being said, it is
> nearly impossible to legislate against, as it would require people to
> avoid declaring namespaces prefix that matches any current or future URI
> scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be in order.

That would deal with collisions; but not with the fact that existing,
non-RDFa consumers, will not expect that an indirection mechanism has
been added.

(And yes, I'm familiar with the P.O.V. that HTML4 requires new rel
values to be opted-in through a @profile; however the real world shows
almost nobody has been doing it, *including* RDFa).

BR, Julian

[Manu Sporny]

Julian Reschke wrote:

>> The technical issue is that it is theoretically possible to construct
>> a rel value which has a list of URIs which could be accidentally
>> interpreted as a list of CURIEs.  Consider the following:
>>
>> <a xmlns:urn="http://purl.org/dc/terms/"
>>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>>    href="http://example.com/terms_of_service.html" >
>>
>> My take: while it is possible to construct such examples, in practice
>> they would be rare enough to not be an issue.  That being said, it is
>> nearly impossible to legislate against, as it would require people to
>> avoid declaring namespaces prefix that matches any current or future
>> URI scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be
>> in order.
>
> That would deal with collisions; but not with the fact that existing,
> non-RDFa consumers, will not expect that an indirection mechanism has
> been added.

Julian, assume that we adopt the language the Sam has specified above.

Why would existing non-RDFa consumers need to know or care? Does it
create any sort of technical issue with pre-existing HTML consumers that
we know about? Wouldn't existing consumers merely ignore the CURIE
values or do nothing with them? Which current HTML parser or toolchain
implementation are we concerned about affecting?

-- manu

--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

[Julian Reschke]

Manu Sporny wrote:

> Julian Reschke wrote:
>>> The technical issue is that it is theoretically possible to construct
>>> a rel value which has a list of URIs which could be accidentally
>>> interpreted as a list of CURIEs.  Consider the following:
>>>
>>> <a xmlns:urn="http://purl.org/dc/terms/"
>>>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>>>    href="http://example.com/terms_of_service.html" >
>>>
>>> My take: while it is possible to construct such examples, in practice
>>> they would be rare enough to not be an issue.  That being said, it is
>>> nearly impossible to legislate against, as it would require people to
>>> avoid declaring namespaces prefix that matches any current or future
>>> URI scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be
>>> in order.
>> That would deal with collisions; but not with the fact that existing,
>> non-RDFa consumers, will not expect that an indirection mechanism has
>> been added.
>
> Julian, assume that we adopt the language the Sam has specified above.
>
> Why would existing non-RDFa consumers need to know or care? Does it
> create any sort of technical issue with pre-existing HTML consumers that
> we know about? Wouldn't existing consumers merely ignore the CURIE
> values or do nothing with them? Which current HTML parser or toolchain
> implementation are we concerned about affecting?

I'm concerned about consumers that treat the contents of @rel as a set
of whitespace-separated tokens, thus seeing "urn:rights" (incorrect) and
"urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" (correct) in the example
above.

BR, Julian

[Manu Sporny]

Julian Reschke wrote:

> Manu Sporny wrote:
>> Julian Reschke wrote:
>>>> The technical issue is that it is theoretically possible to construct
>>>> a rel value which has a list of URIs which could be accidentally
>>>> interpreted as a list of CURIEs.  Consider the following:
>>>>
>>>> <a xmlns:urn="http://purl.org/dc/terms/"
>>>>    rel="urn:rights urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"
>>>>    href="http://example.com/terms_of_service.html" >
>>>>
>>>> My take: while it is possible to construct such examples, in practice
>>>> they would be rare enough to not be an issue.  That being said, it is
>>>> nearly impossible to legislate against, as it would require people to
>>>> avoid declaring namespaces prefix that matches any current or future
>>>> URI scheme.  Perhaps a "SHOULD avoid well known URI schemes" might be
>>>> in order.
>>> That would deal with collisions; but not with the fact that existing,
>>> non-RDFa consumers, will not expect that an indirection mechanism has
>>> been added.
>>
>> Julian, assume that we adopt the language the Sam has specified above.
>>
>> Why would existing non-RDFa consumers need to know or care? Does it
>> create any sort of technical issue with pre-existing HTML consumers that
>> we know about? Wouldn't existing consumers merely ignore the CURIE
>> values or do nothing with them? Which current HTML parser or toolchain
>> implementation are we concerned about affecting?
>
> I'm concerned about consumers that treat the contents of @rel as a set
> of whitespace-separated tokens, thus seeing "urn:rights" (incorrect) and
> "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" (correct) in the example
> above.

What is the worst thing that could happen, as far as you are concerned,
if a consumer saw/stored both "urn:rights" and
"urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a", verbatim? What is the
damage done to the Web if the practice becomes widespread?

Also, what is in your set of acceptable solutions to the issue -
assuming that we adopt Sam's "SHOULD avoid well known URI schemes"
language, and ensuring that there is backwards compatability for RDFa?
Similarly, what is your ideal solution?

-- manu

--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

[Julian Reschke]

Manu Sporny wrote:
> What is the worst thing that could happen, as far as you are concerned,
> if a consumer saw/stored both "urn:rights" and
> "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a", verbatim? What is the
> damage done to the Web if the practice becomes widespread?

With "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" there is no problem
-- it looks like a full URI and it is.

With "urn:rights" there is the problem that the consumer gets the wrong
URI, and furthermore there's a real risk that it could get the same
string from a different party, trying to identify a *different* link
relation.

> Also, what is in your set of acceptable solutions to the issue -
> assuming that we adopt Sam's "SHOULD avoid well known URI schemes"
> language, and ensuring that there is backwards compatability for RDFa?
> Similarly, what is your ideal solution?

If I had a solution that is compatible both with RDFa and full-URIs in
@rel, I would already have proposed it. That's why I've been complaining
for so long: I think the use of CURIEs instead of safe-CURIEs in @rel is
a big problem. (It's ok in new attributes, but problematic in @rel/rev).

BR, Julian

[Toby Inkster-4]

On Thu, 2009-07-09 at 16:58 +0200, Julian Reschke wrote:
> If I had a solution that is compatible both with RDFa and full-URIs in
> @rel, I would already have proposed it. That's why I've been
> complaining for so long: I think the use of CURIEs instead of
> safe-CURIEs in @rel is a big problem. (It's ok in new attributes, but
> problematic in @rel/rev).

Safe CURIEs are important in @about/@resource because those attributes
are primarily intended for URIs. The @rel attribute was not previously
used for URIs, so no disambiguation mechanism was needed.

Yes, @rel in *Atom* is a URI, but no previous recommendations for HTML
or XHTML have recommended URIs in @rel, and the current HTML5 draft
doesn't either. Nor am I aware of any widely non-W3C specifications that
use URIs in @rel. Google's rel=canonical and rel=nofollow are simple
tokens. Pingback uses a simple token, and so do microformats. So I'm not
sure where these pre-existing uses of URIs in @rel are supposed to be
found.

If you're concerned by compatibility between HTML's @rel and Atom's
@rel, then don't be. They're completely incompatible. Atom's is not a
token separated list at all.

--
Toby A Inkster
<mailto:mail@...>
<http://tobyinkster.co.uk>

[Manu Sporny]

Julian Reschke wrote:

> Manu Sporny wrote:
>> What is the worst thing that could happen, as far as you are concerned,
>> if a consumer saw/stored both "urn:rights" and
>> "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a", verbatim? What is the
>> damage done to the Web if the practice becomes widespread?
>
> With "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a" there is no problem
> -- it looks like a full URI and it is.
>
> With "urn:rights" there is the problem that the consumer gets the wrong
> URI, and furthermore there's a real risk that it could get the same
> string from a different party, trying to identify a *different* link
> relation.

Right - but what damage is done at that point? How does that ambiguity
translate into a fatal error in an application or a logic error in a
reasoning agent?

Sam's language, "SHOULD avoid well known URI schemes", goes a long way
to prevent the markup above. Do you have another example that could
conceivably be used? http:, ftp: and urn: break the "SHOULD avoid well
known URI schemes" rule. I'm having a difficult time trying to create a
scenario where something bad happens (other than potential ambiguity IF
somebody uses a URI scheme and IF they just happen to use the exact same
string of characters as a page somewhere else on the web).

I understand that these barrage of questions that you feel you have
already answered may be irritating, but we're attempting to thoroughly
understand your position - as there may be subtleties that we have
continued to miss.

>> Also, what is in your set of acceptable solutions to the issue -
>> assuming that we adopt Sam's "SHOULD avoid well known URI schemes"
>> language, and ensuring that there is backwards compatability for RDFa?
>> Similarly, what is your ideal solution?
>
> If I had a solution that is compatible both with RDFa and full-URIs in
> @rel, I would already have proposed it. That's why I've been complaining
> for so long: I think the use of CURIEs instead of safe-CURIEs in @rel is
> a big problem. (It's ok in new attributes, but problematic in @rel/rev).

We discussed this issue at length during the telecon today - we may be
closing in on a solution that would work for you (and the rest of the
"allow unambiguous URLs in @rel/@rev" group).

All of us agreed that we didn't necessarily understand the problems
resulting from what you are describing. We see it as a theoretical issue
with potential real-world implications, but couldn't think of any that
would destabilize the Web or even affect a significant number of people
(<1%, if forced to pull a number out of thin air).

So, we approached it from the standpoint that not being able to place
URLs in @rel/@rev is too restrictive and that we should try to change that.

I believe the consensus during the call today was on an approach that
would change the CURIE processing rules such that anything without a
prefix mapping is understood as a URL by default. This would allow URLs
to be used in @rel/@rev.

Mark is going to detail the proposal in an e-mail to this list in the
next couple of days. You can see the telecon conversation related to the
issue here:

http://www.w3.org/2009/07/09-rdfa-minutes.html#item01

-- manu

--
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

[Julian Reschke]

Toby Inkster wrote:

> On Thu, 2009-07-09 at 16:58 +0200, Julian Reschke wrote:
>> If I had a solution that is compatible both with RDFa and full-URIs in
>> @rel, I would already have proposed it. That's why I've been
>> complaining for so long: I think the use of CURIEs instead of
>> safe-CURIEs in @rel is a big problem. (It's ok in new attributes, but
>> problematic in @rel/rev).
>
> Safe CURIEs are important in @about/@resource because those attributes
> are primarily intended for URIs. The @rel attribute was not previously
> used for URIs, so no disambiguation mechanism was needed.

The @rel attribute previously existed, and was not specified to use
CURIE indirection, thus the change introduced by RDFa (not qualified by
@profile, btw) potentially changes the meaning of existing content.

Furthermore, RDFa is not specified (yet) for HTML; so the interpretation
of @rel depends on the context it appears in (such as DOCTYPE). This is
bad, because in many cases the final consumer of the @rel value (think
XSLT) will not know about the context.

> Yes, @rel in *Atom* is a URI, but no previous recommendations for HTML
> or XHTML have recommended URIs in @rel, and the current HTML5 draft
> doesn't either. Nor am I aware of any widely non-W3C specifications that
> use URIs in @rel. Google's rel=canonical and rel=nofollow are simple
> tokens. Pingback uses a simple token, and so do microformats. So I'm not
> sure where these pre-existing uses of URIs in @rel are supposed to be
> found.
>
> If you're concerned by compatibility between HTML's @rel and Atom's
> @rel, then don't be. They're completely incompatible. Atom's is not a
> token separated list at all.

No, I'm not concerned about the difference to Atom. What I'm concerned
with is the difference to RDFa-less XHTML and HTML.

BR, Julian

[Shane McCarron]

Julian Reschke wrote:
>
> No, I'm not concerned about the difference to Atom. What I'm concerned
> with is the difference to RDFa-less XHTML and HTML.
Oh!  Wow.   Well, in that case NOTHING we could ever do would satisfy
your concern, right?  I mean any interpretation of @rel is by definition
different than what HTML 4 / XHTML 1 / XHTML 1.1 wold have said.  They
don't permit any interpretation at all outside of the pre-defined @rel
values (which RDFa continues to support for that very reason).  Or
rather, they don't permit the interpretation outside of minting some
@profile value and therefore interpreting the values in @rel as ANYTHING.

Am I missing something here?


--
Shane P. McCarron                          Phone: [phone] x120
Managing Director                            Fax: [phone]
ApTest Minnesota                            Inet: shane@...

[Julian Reschke]

Manu Sporny wrote:
>> With "urn:rights" there is the problem that the consumer gets the wrong
>> URI, and furthermore there's a real risk that it could get the same
>> string from a different party, trying to identify a *different* link
>> relation.
>
> Right - but what damage is done at that point? How does that ambiguity
> translate into a fatal error in an application or a logic error in a
> reasoning agent?

I think that's pretty obvious, right? Two different relations would be
treated as a single one.

> ...
> So, we approached it from the standpoint that not being able to place
> URLs in @rel/@rev is too restrictive and that we should try to change that.

Sounds good.

> I believe the consensus during the call today was on an approach that
> would change the CURIE processing rules such that anything without a
> prefix mapping is understood as a URL by default. This would allow URLs
> to be used in @rel/@rev.

Which is good.

It's still not optimal that adding an xmlns declaration somewhere else
would affect the semantics, though. (And yes, I understand that the
problem can only be *fully* resolved by either breaking RDFa or
URIs-in-rel-values, which is exactly why I did complain loudly one year
ago).

> ...

BR, Julian

[Julian Reschke]

Shane McCarron wrote:

> Julian Reschke wrote:
>>
>> No, I'm not concerned about the difference to Atom. What I'm concerned
>> with is the difference to RDFa-less XHTML and HTML.
> Oh!  Wow.   Well, in that case NOTHING we could ever do would satisfy
> your concern, right?  I mean any interpretation of @rel is by definition
> different than what HTML 4 / XHTML 1 / XHTML 1.1 wold have said.  They
> don't permit any interpretation at all outside of the pre-defined @rel
> values (which RDFa continues to support for that very reason).  Or
> rather, they don't permit the interpretation outside of minting some
> @profile value and therefore interpreting the values in @rel as ANYTHING.
>
> Am I missing something here?

Nothing, except that the requirement to qualify new values with @profile
both was ignored by almost everybody (including RDFa!), and also doesn't
work in practice (as it doesn't help with disambiguation).

BR, Julian