Ben Adida ha scritto:
Ian Hickson wrote:
We have to make sure that whatever we specify in HTML5 actually is going
to be useful for the purpose it is intended for. If a feature intended for
wide-scale automated data extraction is especially susceptible to spamming
attacks, then it is unlikel
On 10/1/09 00:37, Ian Hickson wrote:
On Fri, 9 Jan 2009, Ben Adida wrote:
Is inherent resistance to spam a condition (even a consideration) for
HTML5?
We have to make sure that whatever we specify in HTML5 actually is going
to be useful for the purpose it is intended for. If a feature intended
On Fri, 9 Jan 2009, Ben Adida wrote:
>
> SearchMonkey, which you continue to ignore, is an important use case.
When did I ignore it? I discussed it in depth in my e-mail in December,
listing a number of use cases and requirements that I thought it
demonstrated, and asking if there were any othe
Ian Hickson wrote:
> We have to make sure that whatever we specify in HTML5 actually is going
> to be useful for the purpose it is intended for. If a feature intended for
> wide-scale automated data extraction is especially susceptible to spamming
> attacks, then it is unlikely to be useful for
Tab Atkins Jr. wrote:
> To answer your specific question, is under the control of the
> site author, and search engines already have elaborate methods to tell
> a spammy site from a hammy one, thus downranking them.
And RDFa is also entirely under the control of the site author.
> On the other h
On Fri, 9 Jan 2009, Ben Adida wrote:
>
> Is inherent resistance to spam a condition (even a consideration) for
> HTML5?
We have to make sure that whatever we specify in HTML5 actually is going
to be useful for the purpose it is intended for. If a feature intended for
wide-scale automated data
On Fri, Jan 9, 2009 at 5:13 PM, Ben Adida wrote:
> Tab Atkins Jr. wrote:
>> This brings up different issues, however.
>
> Is inherent resistance to spam a condition (even a consideration) for
> HTML5? If so, where is the concern around , which is clearly
> featured in search engine results?
Well,
Tab Atkins Jr. wrote:
> This brings up different issues, however.
Is inherent resistance to spam a condition (even a consideration) for
HTML5? If so, where is the concern around , which is clearly
featured in search engine results?
-Ben
We started putting a wiki page together for this that will be kept up
to date here:
http://esw.w3.org/topic/foaf+ssl
Henry
On 9 Jan 2009, at 00:28, Story Henry wrote:
Dear WhatWG,
I just subscribed to this list having noticed a thread earlier this
month on the topic of the tag. As it ha
Adam Barth wrote:
On Fri, Jan 9, 2009 at 10:42 AM, Boris Zbarsky wrote:
3) Those for which the URI is same-origin with itself but no other URI
(not to be confused with the globally unique identifier case).
Can you give an example of this kind of URI?
Yes, of course. IMAP URIs [1] have an
On Fri, Jan 9, 2009 at 3:22 PM, Ben Adida wrote:
> Tab Atkins Jr. wrote:
>> However, Ian has a point in his first paragraph. SearchMonkey does
>> *not* do auto-discovery; it relies entirely on site owners telling it
>> precisely what data to extract, where it's allowed to extract it from,
>> and
Ben Adida ha scritto:
Tab Atkins Jr. wrote:
Actually, SearchMonkey is an excellent use case, and provides a
problem statement.
I'm surprised, but very happily so, that you agree.
My confusion stems from the fact that Ian clearly mentioned SearchMonkey
in his email a few days ago, then
Tab Atkins Jr. wrote:
> However, Ian has a point in his first paragraph. SearchMonkey does
> *not* do auto-discovery; it relies entirely on site owners telling it
> precisely what data to extract, where it's allowed to extract it from,
> and how to present it.
That's incorrect.
You can build a S
On Fri, Jan 9, 2009 at 10:42 AM, Boris Zbarsky wrote:
> 3) Those for which the URI is same-origin with itself but no other URI
> (not to be confused with the globally unique identifier case).
Can you give an example of this kind of URI?
Thanks,
Adam
On Fri, Jan 9, 2009 at 2:17 PM, Ben Adida wrote:
> Tab Atkins Jr. wrote:
>> Actually, SearchMonkey is an excellent use case, and provides a
>> problem statement.
>
> I'm surprised, but very happily so, that you agree.
>
> My confusion stems from the fact that Ian clearly mentioned SearchMonkey
> i
Tab Atkins Jr. wrote:
> Actually, SearchMonkey is an excellent use case, and provides a
> problem statement.
I'm surprised, but very happily so, that you agree.
My confusion stems from the fact that Ian clearly mentioned SearchMonkey
in his email a few days ago, then proceeded to say it wasn't a
On Fri, Jan 9, 2009 at 1:48 PM, Ben Adida wrote:
> Julian Reschke wrote:
>>> Because the issue is that we don't yet know if we want to support
>>> RDFa. That's the whole point of this thread. Nobody's given a useful
>>> problem statement yet, so we can't evaluate whether there's a problem
>>> we
Julian Reschke ha scritto:
Calogero Alex Baldacchino wrote:
...
This is why I was thinking about somewhat "data-rdfa-about",
"data-rdfa-property", "data-rdfa-content" and so on, so that, for the
purposes of an RDFa processor working on top of HTML5 UAs (perhaps in
a test phase, if needed at a
Julian Reschke wrote:
>> Because the issue is that we don't yet know if we want to support
>> RDFa. That's the whole point of this thread. Nobody's given a useful
>> problem statement yet, so we can't evaluate whether there's a problem
>> we need to solve, or how we should solve it.
>
> For the
Tab Atkins Jr. wrote:
*If* we want to support RDFa, why not add the attributes the way they are
already named???
Because the issue is that we don't yet know if we want to support
RDFa. That's the whole point of this thread. Nobody's given a useful
problem statement yet, so we can't evaluate w
On Fri, Jan 9, 2009 at 5:46 AM, Julian Reschke wrote:
> Calogero Alex Baldacchino wrote:
>>
>> ...
>> This is why I was thinking about somewhat "data-rdfa-about",
>> "data-rdfa-property", "data-rdfa-content" and so on, so that, for the
>> purposes of an RDFa processor working on top of HTML5 UAs (
I've recently come across another issue with the origin definition.
Right now, this says:
1) If url does not use a server-based naming authority, or if parsing
url failed, or if url is not an absolute URL, then return a new
globally unique identifier.
2) Return the tuple (scheme, host, por
Calogero Alex Baldacchino wrote:
> That is, choosing a proper level of integration for RDF(a) support into
> a web browser might divide success from failure. I don't know what's the
> best possible level, but I guess the deepest may be the worst, thus
> starting from an external support through out
Calogero Alex Baldacchino wrote:
...
This is why I was thinking about somewhat "data-rdfa-about",
"data-rdfa-property", "data-rdfa-content" and so on, so that, for the
purposes of an RDFa processor working on top of HTML5 UAs (perhaps in a
test phase, if needed at all, of course), an element d
24 matches
Mail list logo
