From cam at mcc.id.au  Thu Jan  1 00:57:57 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Thu, 1 Jan 2009 19:57:57 +1100
Subject: [whatwg] Return type of HTMLCanvasElement::getContext()
Message-ID: <20090101085757.GA11964@arc.mcc.id.au>

I think the return type of HTMLCanvasElement::getContext() should go
back to being an object instead of any.  I don?t see any situation where
that method would usefully return a non-object value.  I suggest just
using ?Object? instead of ?DOMObject?, too.  DOMObject is just a
typedef for Object in DOM Core.

-- 
Cameron McCormack ? http://mcc.id.au/


From cam at mcc.id.au  Thu Jan  1 00:59:35 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Thu, 1 Jan 2009 19:59:35 +1100
Subject: [whatwg] Misnamed attribute on HTMLFormElement
Message-ID: <20090101085935.GB11964@arc.mcc.id.au>

The IDL currently says:

  interface HTMLFormElement ? {
    attribute DOMString accept-charset;
    ?
  };

I assume that should be acceptCharset?  If you are actually wanting a
property on an ES host object named ?accept-charset?, then some
additional functionality in Web IDL to define that will be needed.

-- 
Cameron McCormack ? http://mcc.id.au/


From cam at mcc.id.au  Thu Jan  1 01:14:06 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Thu, 1 Jan 2009 20:14:06 +1100
Subject: [whatwg] Window::showModalDialog() missing [Variadic]
Message-ID: <20090101091406.GC11964@arc.mcc.id.au>

The >1 argument version of Window::showModalDialog() is missing a
[Variadic] on the second argument:

  interface Window {
    ?
    any showModalDialog(in DOMString url);
    any showModalDialog(in DOMString url, in any arguments);
    ?
  };

Since no arguments need be passed for those designated with [Variadic],
the two operations could just be combined into one:

  interface Window {
    ?
    any showModalDialog(in DOMString url, [Variadic] in any arguments);
    ?
  };

-- 
Cameron McCormack ? http://mcc.id.au/


From timeless at gmail.com  Thu Jan  1 02:59:43 2009
From: timeless at gmail.com (timeless)
Date: Thu, 1 Jan 2009 12:59:43 +0200
Subject: [whatwg] Misnamed attribute on HTMLFormElement
In-Reply-To: <20090101085935.GB11964@arc.mcc.id.au>
References: <20090101085935.GB11964@arc.mcc.id.au>
Message-ID: <26b395e60901010259k4edd204aufd2b862dcfc4abd3@mail.gmail.com>

On Thu, Jan 1, 2009 at 10:59 AM, Cameron McCormack <cam at mcc.id.au> wrote:
> The IDL currently says:
>
>  interface HTMLFormElement ? {
>    attribute DOMString accept-charset;
>    ?
>  };
>
> I assume that should be acceptCharset?  If you are actually wanting a
> property on an ES host object named "accept-charset", then some
> additional functionality in Web IDL to define that will be needed.

I would really how web idl would not support that feature :)


From mail at tobyinkster.co.uk  Thu Jan  1 07:24:50 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Thu, 1 Jan 2009 15:24:50 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
Message-ID: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>

The use cases for RDFa are pretty much the same as those for  
Microformats.

For example, if a person's name and contact details are marked up on  
a web page using hCard, the user-agent can offer to, say, add the  
person to your address book, or add them as a friend on a social  
networking site, or add a reminder about that person's birthday to  
your calendar.

If an event is marked up on a web page using hCalendar, then the user- 
agent could offer to add it to a calendar, or provide the user with a  
map of its location, or add it to a timeline that the user is  
building for their school history project.

Providing rich semantics for the information on a web page allows the  
user-agent to know what's on a page, and step in and perform helpful  
tasks for the user.

So why RDFa and not Microformats?

Firstly, RDFa provides a single unified parsing algorithm that  
Microformats do not. Separate parsers need to be created for  
hCalendar, hReview, hCard, etc, as each Microformat has its own  
unique parsing quirks. For example, hCard has N-optimisation and ORG- 
optimisation which aren't found in hCalendar. With RDFa, a single  
algorithm is used to parse everything: contacts, events, places,  
cars, songs, whatever.

Secondly, as the result of having one single parsing algorithm,  
decentralised development is possible. If I want a way of marking up  
my iguana collection semantically, I can develop that vocabulary  
without having to go through a central authority. Because URIs are  
used to identify vocabulary terms, I can be sure that my vocabulary  
won't clash with other people's vocabularies. It can be argued that  
going through a community to develop vocabularies is beneficial, as  
it allows the vocabulary to be built by "many minds" - RDFa does not  
prevent this, it just gives people alternatives to community  
development.

Lastly, there are a lot of parsing ambiguities for many Microformats.  
One area which is especially fraught is that of scoping. The editors  
of many current draft Microformats[1] would like to allow page  
authors to embed licensing data - e.g. to say that a particular  
recipe for a pie is licensed under a Creative Commons licence.  
However, it has been noted that the current rel=license Microformat  
can not be re-used within these drafts, because virtually all  
existing rel=license implementations will just assume that the  
license applies to the whole page rather than just part of it. RDFa  
has strong and unambiguous rules for scoping - a license, for  
example, could apply to a section of the page, or one particular image.

RDFa was largely borne of looking at Microformats, looking at what  
was successful about them, considering problems with them, and  
finding ways to resolve those problems.

____
1. It has been discussed in hAudio, figure, hRecipe and others.

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




From alex.baldacchino at email.it  Thu Jan  1 10:17:49 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Thu, 01 Jan 2009 19:17:49 +0100
Subject: [whatwg] Spellchecking mark III
In-Reply-To: <6E21D56C-D8D1-4135-B434-44824351CC6E@apple.com>
References: <Pine.LNX.4.62.0606221603330.4826@dhalsim.dreamhost.com>	<00be01c69880$ca66fa20$3401a8c0@TERRA>
	<449F56E8.5030309@earthlink.net>	<003001c69991$55e53470$3401a8c0@TERRA>	<Pine.LNX.4.62.0606292229500.4826@dhalsim.dreamhost.com>	<44ACEBF1.30408@mozilla.org>	<Pine.LNX.4.62.0812301132260.24109@hixie.dreamhostps.com>	<DAD4B7D1-FC53-449D-8B91-EF4BE6C0232D@googlemail.com>	<8AD09628-5B9E-4D0F-BC76-8FA930E0B1DD@geekhood.net>	<EE328737-8692-4C7E-8B8C-32BF7C987DFE@apple.com>	<11e306600812311226w6969190fv50c19033c4d73a36@mail.gmail.com>
	<6E21D56C-D8D1-4135-B434-44824351CC6E@apple.com>
Message-ID: <495D08CD.4030806@email.it>

Maciej Stachowiak ha scritto:
>
> On Dec 31, 2008, at 12:26 PM, Robert O'Callahan wrote:
>
>> On Thu, Jan 1, 2009 at 4:15 AM, Maciej Stachowiak <mjs at apple.com 
>> <mailto:mjs at apple.com>> wrote:
>>
>>     2) The proposal Hixie linked seems way overengineered for this
>>     purpose. First, it allows spellchecking to be explicitly turned
>>     on, potentially overriding normal defaults, but that seems wrong;
>>     an <input type="email"> should never spellcheck regardless of the
>>     page author says. I can't see any valid use case for the author
>>     turning spellchecking on regardless of UA defaults or user
>>     preferences.
>>
>>
>> It allows you to have a region of text where spellchecking is 
>> disabled via the spellcheck attribute, but containing subregions 
>> where spellchecking is enabled.
>
> It seems to me you would have to have a lot of custom code to maintain 
> the boundaries between such regions during editing operations for this 
> to ever work right. Normal text editing would easily lead to text 
> moving across the boundaries. There would have to be strong motivating 
> examples to justify such a hard-to-use feature.
>

Do you mean a lot of code for a UA or for a webapp developer? As far as 
I can tell (and guess), in both cases one could make things easy, just 
ckecking for mispelled words basing on where a bounch of text is pasted 
in, using an element with a certain behaviour as a fixed boundary (as 
when some text is copied and pasted from a box to another after the user 
has disallowed, for some reason, spell checking for only one of them - 
if allowed by the UA). As far as boxes are styled and described in order 
to make it clear for the user what's going on (and the UA provides a 
mean to bypass an author's choice -- as it happens when users don't 
allow a script to intercept right clicks), that should work fine.

Otherwise, if a finer granularity in felt as necessary to correctly 
implement such (e.g. to allow a user to modify a certain region 
boundaries), I think that's not very different than changing a random 
selection style in a rich text editor (= same algorithms might be used 
to determine boundaries).

>>
>>     Second, it allows spellchecking to be controlled at a finer
>>     granularity than editability, for which again I think there is no
>>     valid use case. Both of these aspects make the feature more
>>     complicated to implement and harder to understand, compared to
>>     just having a way to only disable spellchecking at the same
>>     granularity as editing.
>>
>> A use case is editable program code, where spellchecking is disabled, 
>> but where spellchecking is enabled inside comments. Maybe that sounds 
>> a little far-fetched for today's Web applications, but some IDEs 
>> (e.g. Eclipse) support this so it seems like something we'd want in 
>> the future.
>
> This sounds like a pretty ill-conceived feature. It is very common for 
> comments to include code, or fragments of code (such as variable 
> names) mixed with natural language. (I was unable to find any evidence 
> of spellchecking comments in the copy of Eclipse I downloaded, so I 
> can't comment on the details.)
>

Well, a few outlined words shouldn't be so bothering as (almost) 
everything you write being marked as misspelled while writing one's 
code... Anyway, either the editor interface or the UA (bypassing it) 
might allow the user to change the default/authored behaviour at will, 
thus one might first wright a comment, then enable spell checking to 
verify no words other than code fragments are misspelled, and lastly 
disable it to make any annoying underscore disappear.

Furthermore, a user might be allowed to turn off any checking for a 
certain word (in its first occurrence, or for the whole document), as it 
happens in wordprocessors when ignoring a misspelled term, and which may 
be a natural evolution for UAs' spell checkers. Or, perhaps, a code 
fragment might be put inside a further, unchecked subregion created by 
mean of some option in the editor interface.

> Furthermore, other IDEs generally don't attempt to do this, and I 
> can't think of other application categories that would do something 
> similar.
>

Well, historically IDEs didn't had a built-in spell checker, while 
latest browsers do have, thus such might be or become a value added in a 
web-based IDE, if used "cum grano salis".

However, I have no strong feeling for "spellcheck" vs "nospellcheck", as 
proposed by Kornel Lesi?ski, I can see a few use cases for both, and 
perhaps possible solutions to thecnical problems implementing them. I 
think a bit of control over spell checking may be useful, and spell 
checking might be worth to be takent into account by standards as a 
feature going to be widespread in current and future web browsers. I 
guess introducing such an attribute (or the alike) would have 
consequences for styling, and perhaps influence CSS, for instance by 
suggesting the introduction of a ":misspelled" pseudo element (or the 
alike) to allow a proper styling of mispelled words (according to an 
editable element style) -- though such might be proposed independently; 
I'm just considering there are reasons to take spell checking into 
account for web related standards, since browsers are implementing such 
a feature.

Best regards and happy 2009,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Prova il servizio di Email Marketing di Email.it, incrementi la visibilita' della tua azienda e trovi nuovi clienti.
* Liste a partire da 10.000 contatti per soli 250 Euro
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8351&d=1-1


From andi at takkaria.org  Thu Jan  1 10:43:05 2009
From: andi at takkaria.org (Andi Sidwell)
Date: Thu, 01 Jan 2009 18:43:05 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
Message-ID: <495D0EB9.3090407@takkaria.org>

On 2009-01-01 15:24, Toby A Inkster wrote:
> The use cases for RDFa are pretty much the same as those for Microformats.

Right, but microformats can be used without any changes to the HTML 
language, whereas RDFa requires such changes.  If they fulfill the same 
use cases, then there's not much point in adding RDFa.

> For example, if a person's name and contact details are marked up on a
> web page using hCard, the user-agent can offer to, say, add the person
> to your address book, or add them as a friend on a social networking
> site, or add a reminder about that person's birthday to your calendar.
>
> If an event is marked up on a web page using hCalendar, then the
> user-agent could offer to add it to a calendar, or provide the user with
> a map of its location, or add it to a timeline that the user is building
> for their school history project.
>
> Providing rich semantics for the information on a web page allows the
> user-agent to know what's on a page, and step in and perform helpful
> tasks for the user.
>
> So why RDFa and not Microformats?
>
> Firstly, RDFa provides a single unified parsing algorithm that
> Microformats do not. Separate parsers need to be created for hCalendar,
> hReview, hCard, etc, as each Microformat has its own unique parsing
> quirks. For example, hCard has N-optimisation and ORG-optimisation which
> aren't found in hCalendar. With RDFa, a single algorithm is used to
> parse everything: contacts, events, places, cars, songs, whatever.

This is not necessarily beneficial.  If you have separate parsing 
algorithms, you can code in shortcuts for common use-cases and thus 
optimise the authoring experience.  Also, as has been pointed out before 
in the distributed extensibility debate, parsing is a very small part of 
doing useful things with content.

> Secondly, as the result of having one single parsing algorithm,
> decentralised development is possible. If I want a way of marking up my
> iguana collection semantically, I can develop that vocabulary without
> having to go through a central authority.

You can develop vocabularies without going through a central authority 
already, via class or id, and many people already do.

> Because URIs are used to
> identify vocabulary terms, I can be sure that my vocabulary won't clash
> with other people's vocabularies.

Again, you can do this with class, by putting your domain name in the 
class attribute.  It also depends on how much of an issue you think 
clashes will be with an iguana collection-- I would suggest that due to 
the specialised nature of the markup, clashes would be quite unlikely.

> It can be argued that going through a
> community to develop vocabularies is beneficial, as it allows the
> vocabulary to be built by "many minds" - RDFa does not prevent this, it
> just gives people alternatives to community development.

RDFa does not give anything over what the class attribute does in terms 
of community vs individual development, so this doesn't really speak in 
RDFa's favour.

> Lastly, there are a lot of parsing ambiguities for many Microformats.
> One area which is especially fraught is that of scoping. The editors of
> many current draft Microformats[1] would like to allow page authors to
> embed licensing data - e.g. to say that a particular recipe for a pie is
> licensed under a Creative Commons licence. However, it has been noted
> that the current rel=license Microformat can not be re-used within these
> drafts, because virtually all existing rel=license implementations will
> just assume that the license applies to the whole page rather than just
> part of it. RDFa has strong and unambiguous rules for scoping - a
> license, for example, could apply to a section of the page, or one
> particular image.

Are there other cases where this granularity of scoping would be 
genuinely helpful?  If not, it would seem better to work out a solution 
for scoping licence information instead of bringing in a whole new 
vocabulary to solve it.

What would you do with scoped copyright information, anyway?  I can see 
images being an issue, but ideally information about a resource should 
be kept in that resource, and as such the licence should be embedded in 
the image rather than given by a Web page.  In the case of particular 
sections having particular licences, is there any practical use of 
marking up different sections with different licences over just doing 
that with text?

> RDFa was largely borne of looking at Microformats, looking at what was
> successful about them, considering problems with them, and finding ways
> to resolve those problems.

Andi


From cam at mcc.id.au  Thu Jan  1 17:35:18 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Fri, 2 Jan 2009 12:35:18 +1100
Subject: [whatwg] Window::applicationCache missing
Message-ID: <20090102013518.GC14295@arc.mcc.id.au>

The applicationCache attribute on the Window interface seems to be
missing.

-- 
Cameron McCormack ? http://mcc.id.au/


From chaals at opera.com  Thu Jan  1 22:12:55 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Fri, 02 Jan 2009 17:12:55 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495D0EB9.3090407@takkaria.org>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<495D0EB9.3090407@takkaria.org>
Message-ID: <op.um38vt1gwxe0ny@widsithpro.lan>

On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell <andi at takkaria.org> wrote:

> On 2009-01-01 15:24, Toby A Inkster wrote:
>> The use cases for RDFa are pretty much the same as those for  
>> Microformats.
>
> Right, but microformats can be used without any changes to the HTML  
> language, whereas RDFa requires such changes.  If they fulfill the same  
> use cases, then there's not much point in adding RDFa.
...
>> So why RDFa and not Microformats?

(I think the question should be why RDFa is needed *as well as* ?formats)

>> Firstly, RDFa provides a single unified parsing algorithm that
>> Microformats do not. ...

> This is not necessarily beneficial.  If you have separate parsing  
> algorithms, you can code in shortcuts for common use-cases and thus  
> optimise the authoring experience.

On the other hand, you cannot parse information until you know how it is  
encoded, and information encoded in RDFa can be parsed without knowing  
more.

And not only can you optimise your parsing for a given algorithm, you can  
also do for a known vocabulary - or you can optimise the post-parsing  
treatment.

>  Also, as has been pointed out before in the distributed extensibility  
> debate, parsing is a very small part of doing useful things with content.

Yes. However many of the use cases that I think justify the inclusion of  
RDFa are already very small on their own, and valuable when several  
vocabularies are combined. So being able to do off-the-shelf parsing is  
valuable, compared to working out how to parse a combination of formats  
together.

>> Secondly, as the result of having one single parsing algorithm,
>> decentralised development is possible. If I want a way of marking up my
>> iguana collection semantically, I can develop that vocabulary without
>> having to go through a central authority.
>
> You can develop vocabularies without going through a central authority  
> already, via class or id, and many people already do.
>
>> Because URIs are used to
>> identify vocabulary terms, I can be sure that my vocabulary won't clash
>> with other people's vocabularies.
>
> Again, you can do this with class, by putting your domain name in the  
> class attribute.  It also depends on how much of an issue you think  
> clashes will be with an iguana collection-- I would suggest that due to  
> the specialised nature of the markup, clashes would be quite unlikely.

It depends how many people work on iguana collections - or Old Norse and  
Anglo Saxon text, which was the use case that got me involved in the Web  
in the very early 90s. It turns out that people don't, in the ?formats  
world, use unambiguous names, especially when they are privately  
developing their own information. By contrast, those who come from an RDF  
world do this by habit.

>> It can be argued that going through a
>> community to develop vocabularies is beneficial, as it allows the
>> vocabulary to be built by "many minds" - RDFa does not prevent this, it
>> just gives people alternatives to community development.
>
> RDFa does not give anything over what the class attribute does in terms  
> of community vs individual development, so this doesn't really speak in  
> RDFa's favour.

In principle no, but in real world usage the class attribute is considered  
something that is primarily local, whereas RDFa is generally used by  
people who have a broader outlook on the desirable permanence and  
re-usability of their data.

>> Lastly, there are a lot of parsing ambiguities for many Microformats.
>> One area which is especially fraught is that of scoping. The editors of
>> many current draft Microformats[1] would like to allow page authors to
>> embed licensing data - e.g. to say that a particular recipe for a pie is
>> licensed under a Creative Commons licence. However, it has been noted
>> that the current rel=license Microformat can not be re-used within these
>> drafts, because virtually all existing rel=license implementations will
>> just assume that the license applies to the whole page rather than just
>> part of it. RDFa has strong and unambiguous rules for scoping - a
>> license, for example, could apply to a section of the page, or one
>> particular image.
>
> Are there other cases where this granularity of scoping would be  
> genuinely helpful?  If not, it would seem better to work out a solution  
> for scoping licence information...

Yes.

Being able to describe accessibility of various parts of content, or point  
to potential replacement content for particular use cases, benefits  
enormously from such scoping (this is why people who do industrial-scale  
accessibility often use RDF as their infrastructure). ARIA has already  
taken the approach of looking for a special-purpose way to do this, which  
significantly bloats HTML but at least allows important users to satisfy  
their needs to be able t produce content with certain information included.

Government and large enterprises produce content that needs to be  
maintained, and being able to include production, cataloguing, and similar  
metadata directly, scoped to the document, would be helpful. As a trivial  
example, it would be useful to me in working to improve the Web content we  
produce at Opera to have a nice mechanism for identifying the original  
source of various parts of a page.

> What would you do with scoped copyright information, anyway?  I can see  
> images being an issue, but ideally information about a resource should  
> be kept in that resource, and as such the licence should be embedded in  
> the image rather than given by a Web page.  In the case of particular  
> sections having particular licences, is there any practical use of  
> marking up different sections with different licences over just doing  
> that with text?

Mash-ups. If they have a use-case, and I think it is widely accepted that  
they do, then it would seem obvious that being able to identify the source  
of each part, and any conditions that vary between different sources, is a  
use case.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From hsivonen at iki.fi  Fri Jan  2 02:38:33 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 2 Jan 2009 12:38:33 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
Message-ID: <7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>

On Jan 1, 2009, at 17:24, Toby A Inkster wrote:

> So why RDFa and not Microformats?

There's a possibility that this is a false dichotomy and both are bad.

> Firstly, RDFa provides a single unified parsing algorithm that  
> Microformats do not. Separate parsers need to be created for  
> hCalendar, hReview, hCard, etc, as each Microformat has its own  
> unique parsing quirks. For example, hCard has N-optimisation and ORG- 
> optimisation which aren't found in hCalendar. With RDFa, a single  
> algorithm is used to parse everything: contacts, events, places,  
> cars, songs, whatever.

More to the point, Microformats not only require per-format processing  
but the processing required for each Microformat isn't specified at  
all. That's bad.

RDFa, on the other hand, uses CURIEs, which is bad. (More generally, I  
think using URIs as identifiers instead of using them for above-TCP- 
layer protocol addressing is bad, but relying on the namespace mapping  
context is even worse.)

Have there been any attempts to remove the badness of Microformats  
without introducing the badness of RDFa in the process? That is, have  
there been attempts of defining unified parsing while retaining the  
feel of Microformats without relying on the namespace mapping context  
from the layer below?

If not, why not? I'm assuming that people in the Microformat community  
have clue. Yet, on the face of it, viewed from outside the community,  
their formats seem to have a big problem. Why hasn't the community  
fixed it? Is it a non-problem after all in practice?

> Lastly, there are a lot of parsing ambiguities for many  
> Microformats. One area which is especially fraught is that of  
> scoping. The editors of many current draft Microformats[1] would  
> like to allow page authors to embed licensing data - e.g. to say  
> that a particular recipe for a pie is licensed under a Creative  
> Commons licence. However, it has been noted that the current  
> rel=license Microformat can not be re-used within these drafts,  
> because virtually all existing rel=license implementations will just  
> assume that the license applies to the whole page rather than just  
> part of it. RDFa has strong and unambiguous rules for scoping - a  
> license, for example, could apply to a section of the page, or one  
> particular image.

Is the problem in the case of recipes that the provider of the page  
navigation around the recipe is unwilling to license the navigation  
bits under the same license as the content proper?

In the case of images, why should a program inferring something about  
licensing trust assertions made in a different HTTP resource (possibly  
even from a different Origin)?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From hsivonen at iki.fi  Fri Jan  2 02:58:56 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Fri, 2 Jan 2009 12:58:56 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um19y5ajwxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
Message-ID: <9F72ABC7-E17A-405D-B273-3E767DE72817@iki.fi>

On Jan 1, 2009, at 06:41, Charles McCathieNevile wrote:

> There are many cases where people build their own dataset and  
> queries to solve a local problem. As an example, Opera is not  
> intersted in asking Google to index data related to internal  
> developer documents, and use it to produce further documentation we  
> need. However, we do automatically extract various kinds of data  
> from internal documents and re-use it. While Opera does not in fact  
> use the RDF toolstack for that process, there are many other large  
> companies and organisations who do, and who would benefit from being  
> able to use RDFa in that process.

If the data production and consumption are both under the control of  
one entity (Opera in this case), why does the solution need to be  
engineered for spontaneous integration of decentralized data sources?

Do the savings of using off-the-shelf tools outweigh the cost they  
impose by not being quite right for any specific purpose? Presumably  
the Opera-specific processing is more significant than generic  
parsing. Or is it?

It seems that RDFa is motivated by private data and by interchange at  
the same time. This suggests multiple bilateral access control  
agreements instead of a Web-like system where data is made available  
for GETting without prior agreement between the parties.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From bhawkeslewis at googlemail.com  Fri Jan  2 04:01:34 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Fri, 02 Jan 2009 12:01:34 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>
Message-ID: <495E021E.8010407@googlemail.com>

On 2/1/09 10:38, Henri Sivonen wrote:
> More to the point, Microformats not only require per-format processing
> but the processing required for each Microformat isn't specified at all.
> That's bad.

Some do have processing specified (at least to some degree):

http://microformats.org/wiki/hcard-parsing

For the rest, this seems like something fixable, so I'm not sure how 
this is more to the point?

 > That is, have
> there been attempts of defining unified parsing while retaining the feel
> of Microformats without relying on the namespace mapping context from
> the layer below?

I suppose -

* http://microformats.org/wiki/design-patterns (reusable microformat 
components)

* http://microformats.org/wiki/parsing-brainstorming (attempt to 
actually specify precise parsing rules for all microformats)

* 
http://microformats.org/discuss/mail/microformats-discuss/2008-August/012435.html 
(proposal for specifying generic mapping of microformats to RDF - I 
think there's been more detailed work by various parties in this regard, 
but I'm not sure where best to link to)

- are approaching this problem from three different angles.

> Why hasn't the community fixed it?

I think the microformats community moves slowly, for better or worse, 
even when it agrees that there's a problem to solve. For example, 
progress on the problems with the abbr-design-pattern has been 
snail-like while losing the community an important user (the BBC), 
although admittedly the problems are basically intractable in HTML4/XHTML1.

I'm not sure how far the community as a whole does or doesn't view the 
lack of unified parsing as one of its bigger problems; I'm no spokesman 
though.

> Is it a non-problem after all in practice?

It's an additional barrier to creating and using (especially new) 
microformats or other extractable patterns.

The microformats community isn't there to support the creation of new 
extractable patterns outside the microformats community, which is where 
an iguana database pattern would likely need to be.

It could of course be the RDFa curie is worse than the disease.

An advantage of RDFa that is not related to curies and for which the 
three approaches towards unified extraction mentioned above are not a 
substitute is that RDFa provides a generic way to include hidden 
machine-friendly equivalents to human-readable information in the form 
of the (not especially well-named) "content" attribute.

http://www.w3.org/TR/rdfa-syntax/#rdfa-attributes

In general, this is something microformats rightly try to avoid:

http://microformats.org/wiki/principles

But sometimes it's unavoidable:

http://microformats.org/wiki/machine-data

http://microformats.org/wiki/value-excerption-pattern-issues

I do not believe that HTML5 as currently specified would remove the need 
to employ similar hacks as are mentioned on those pages, although it 
will remove the need in many cases (e.g. for datetimes within a given 
range), which is an improvement.

> Is the problem in the case of recipes that the provider of the page
> navigation around the recipe is unwilling to license the navigation bits
> under the same license as the content proper?

I thought Toby's example was that each recipe on the page needed a 
different licence, rather than a distinction between the main content 
area and the navigation.

> In the case of images, why should a program inferring something about
> licensing trust assertions made in a different HTTP resource (possibly
> even from a different Origin)?

Why should it trust assertions made in the same resource?

For example, presumably you could download an image, change its 
licencing metadata, and host it at your own Origin? Admittedly, that's a 
little more work than just hotlinking.

--
Benjamin Hawkes-Lewis




From jackalmage at gmail.com  Fri Jan  2 08:49:02 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 2 Jan 2009 10:49:02 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um19y5ajwxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
Message-ID: <dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>

On Wed, Dec 31, 2008 at 10:41 PM, Charles McCathieNevile
<chaals at opera.com> wrote:
> A standard way to include arbitrary data in a web page and extract it for
> machine processing, without having to pre-coordinate their data models.

This isn't a requirement (or in other words, a problem), it's a
solution.  What are the problems that need to be solved, and for which
having a standard way to include arbitrary data in a web page and have
it easily extractable would be helpful?  (Note:  I think there
certainly *are* problems that *would* find this helpful, I'm just
trying to lead your argument into the right direction.)  (As well,
since the discussion is about RDFa specifically, not data-markup in
general, what are the problems that need RDFa *specifically* as a
solution, as compared to the myriad other ways to embed data?)

> Since many people use RDF as an interchange, storage and processing format
> for this kind of data (because it provides for automated mapping of data
> from one schema to many others, without requiring anyone to touch the
> original schemata or agree in advance how they should be created), I believe
> there is a requirement for a method that allows third parties to include RDF
> data in, and extract it from information encoded within an HTML page.

Solutions for this already exist; embedded N3 in a <script> tag, just
to name something that Ian already mentioned, allows you to mash RDF
data into a page in a machine-extractable way, and brings in any of
the specific ancillary benefits of RDF.

>>> The Microformats community has done a remarkable job of working on the
>>> web semantics problem, creating several different methods of expressing
>>> common human concepts (contact information (hCard), events (hCalendar),
>>> and audio recordings (hAudio)).
>>
>> Right; with Microformats, each Microformat has its own problem space and
>> thus each one can be evaluated separately. It is much harder to evaluate
>> something when the problem space is as generic as it appears RDFa's is.
>
> The point is that there are a very large set of very small problem spaces
> relevant to a small group at a time. Like RDF itself, RDFa is meeting the
> problem of allowing these people to share machine-processable data without
> previously coordinating their approach.

Not quite correct.  Again, the problem of embedded shareable data in a
web page has been solved multiple times.  The specific problem of
sharing *RDF* data (due to needing/wanting the specific benefits RDF
can offer) has also been solved.  What are the precise problems that
require *RDFa* as a solution?

(I won't belabor this point, though it could be brought up several
times more in your email.  This is and was the primary point of
contention between RDFa supporters and those of us who aren't
convinced it belongs in the HTML5 spec.  It is the major thrust of
much of Ian's email; he's trying to help you (RDFa supporters in
general, that is) find exactly what the problem is that RDFa
specifically is trying to solve.)

> Moreover, that is not actually a very good question in this case. I think
> the judgement call should be whether a syntax that allows people to solve
> the identified problem set consistently is sufficiently valuable (measured
> in terms of the advantages weighed against the disadvantages) to justify
> being part of HTML5.

Well, there are many things that would offer more advantages than
disadvantages by themselves.  We can't possibly include all of them in
the spec; you can think about this as including a hidden large
disadvantage of 'will grow the size of the spec and the amount of work
implementors have to do'.  Thus the advantages must generally be
significantly larger than the disadvantages; this is why the best
argument for including something in the spec is often "there are
already widespread hacks to accomplish this".  <video>, for example,
was included based on pretty much precisely that argument.

Of course, that just means that we've identified a problem that is
significant enough to be solved in the spec.  There is still
significant work involved in ensuring that we identify a solution that
actually hits the problem squarely; the existing hacks are usually
inadequate, not through any true fault of their own, but merely
because they had not considered the problem broadly enough, or lacked
enough eyes to find rough edges and missing spots.

>> What are the advantages?
>
> Many people will be able to use standard tools which are part of their
> existing infrastructure to manipulate important data. They will be able to
> store that data in a visible form, in web pages. They will also be able to
> present the data easily in a form that does not force them to lose important
> semantics.
>
> People will be able to build toolkits that allow for processing of data from
> webpages without knowing, a priori, the data model used for that
> information.

Part of the point of Ian's email is that this is not a problem that is
solved by RDFa, it's a problem that's solved by *any* sufficient data
format.  Many solutions currently exist which don't require any
addition to the spec.


>> What is the
>> opportunity cost of encouraging everyone to expose data in the same way?
>
> I don't know. I don't see much of an opportunity cost.

There is no perfect data model, or perfect representation method.
Every group of data is different, has different ideal representations,
and incurs some degree of cost when forced into an existing data model
(that is, one not tailored to the data's specs).  This must thus be
considered.

>>  - As another example, why doesn't Craigslist like their data being
>> reused in mashups? Would they be willing to allow their users to reuse
>>   their data in these new and exciting ways, or would they go out of
>>   their way to prevent the data from being accessible as soon as a
>>   critical mass of users started using it?
>
> This is a key question. Why *should* a data provider be required to offer
> their product (data) for other people to use, in order to demonstrate that
> the data is useful. Google, a large provider of data, insists on certain
> conditions being met before it makes its services available, and that seems
> perfectly reasonably to me.
>
> Whether Craigslist actively attempts to make their data easier to aggregate,
> or actively avoids facilitating that process, strikes me as irrelevant to
> the question of whether there is value in enabling them to do so. Because
> large organisations specialising in gathering people's data, from Flickr to
> Google and Facebook to Government taxation departments are not the only
> consumers and producers of data that determine value for users.
>
> It would seem important that the Web easily enable small-time users of data
> to efficiently communicate with one another, without the need to have one of
> the giants as an intermediary. When libraries in the Dominican Republic want
> to share data, and librarians in L?on want to use that data, it seems that
> the Web should facilitate that without resorting to intermediaries like
> Amazon or Yahoo! and since we already have the technology to do so in a way
> that enables very powerful data models to be used without requiring
> coordination, it seems odd that you don't even understand how this could be
> valuable.

This is precisely a key question because of many of the arguments that
RDFa supporters have brought up (specifically, in the last flurry of
emails to the group on this subject), that having RDFa will allow web
users to query their browsers, which can then seek out structured data
to answer their questions.  If large websites are not willing to
provide their data to the web-at-large in a structured format, though,
then all the data formats in the world won't accomplish the goal.

In this email, though, you are largely arguing for smaller, more
personal use cases.  Most of the questions are still valid, however.
Problem: Librarians across the world want to share data.  What are the
requirements here?  How is RDFa meet those requirements?  Are there
other solutions which meet those requirements better?  Are existing
solutions adequate if deployed consistently (thus negating the need
for a new technology)?

Specifically, small-time users seem (to me, at least) to need RDFa as
a solution the least.  They can negotiate a shared data format
themselves, or at least present an API that can be engineered against
by others.  RDF itself may be a useful tool here, if it allows reuse
of existing tools and thus simplifies the process of sharing and
consuming the data, but RDFa specifically is a solution for embedding
this data within a web page and allowing browsers to digest it as they
encounter it.  This is not an appropriate solution for the sharing of
catalog data between libraries; it *may* be a solution for the average
web user to have their browser grab the embedded information on a page
for a specific book and query for reviews on the product across the
web.

This, though, then once again brings up the traditional questions.  Is
RDFa the best solution for this?  Are there existing solutions to
this?  Ian specifically mentioned simply Googling for the book title;
this is indeed often quite adequate for a web user.  Does the use of
RDFa and the active involvement of the browser in this process offer
enough of a benefit above just typing a phrase into the search bar to
justify inclusion into the spec?  If you believe so, can you explain
precisely why?

>> Can only previously configured, hard-coded questions be asked,
>> or will Web browsers be able to answer arbitrary free-form questions from
>> users using the data exposed by RDFa?
>
> Both of these are possible. The value of RDFa is that it actually supports
> the possibility of asking free-form questions by using a data model that is
> sufficiently well specified to enable constructions of tools that are not
> dependent on being preconfigured to recognise the exact type of data being
> queried (unlike, say, microformats, which require an intermediate agreement
> to enable people to extract the data, and don't provide for merging data of
> different types for rich queries).

This is not a benefit of RDFa.  It *may* be a benefit of RDF.  What
does RDFa bring to the table that other solutions do not?  What does
it take away?

> Aggregating data in real-time is relatively expensive, so is a strategy more
> suited to dealing with asking new questions. Typical systems so far have
> aggregated data in the background to deal with known queries (one example is
> Google, which crawls pages in advance, anticipating searches that match
> terms against the content of those pages),

Google is a large company, and can indeed invest resources into
trawling and recording such data.  This is explicitly not an option
for the smaller uses you seem to be highlighting in this email,
though.  RDFa is specifically a (very) distributed data storage
system.  Can it address these sorts of problems, if the small-time
users simply can't trawl the entire web for matching information?
When the info is relatively contained (such that finding and reading
the pages it exists on is feasible), is trawling the pages for RDFa
data the best solution?  Are there other solutions which would work
better (such as providing an API for hitting a database)?  Are there
existing solutions which work adequately?

> and use live querying for cases
> where the result cannot reliably be stored (e.g. airline reservation systems
> like TravelJungle or LastMinute which determine price and availability based
> on constantly changing data).

Similarly, would these sites work by trawling reservation sites for
RDFa data?  As well, what if the reservation sites aren't interested
in providing the data in a machine-readable format (for example, if
they want users to go directly to their sites)?  Would it be better
for these types of sites to hit an API provided by the reservation
sites directly?  Would it be better for the discount sites to trawl
with custom algorithms that don't require the cooperation of the
reservation sites?  Within the space of page-embedded data, are there
better solutions, or existing adequate solutions?

>>  - Systems like Yahoo! Search and Live Search expend extraordinary
>> amounts of resources on spam fighting technology; such technology
>>   would not be accessible to Web browsers unless they interacted with
>>   anti-spam services much like browsers today interact with
>>   anti-phishing services.
>
> Actually, at least Opera already incorporates anti-spam technology in its
> mail client. Where browsers are the primary consumers of data there is
> nothing at all to suggest that they cannot incorporate anti-spam technology
> directly. (Indeed, the POWDER specification is designed in part to make that
> easy - and it is exactly the sort of data that might sometimes be usefully
> encoded in RDFa since it is based on an RDF model).

Fighting email spam is a different problem from fighting black-hat SEO
spamming.  The attack surfaces presented by RDFa are much closer to
the latter than the former.

>>  - Even with a mechanism to distinguish trusted sites from spammy sites,
>>   how would Web browsers deal with trusted sites that have been subject
>>   to spamming attacks? This is common, for instance, on blogs or wikis.
>
> Right. But that doesn't mean we question whether browsers should enable
> blogs or wikis. Why would RDFa data be different enough to make this
> question relevant?

Users are interacting with blogs/wikis on a human level, and thus can
exercise their own (admittedly poor in practice) judgement.  This is a
different problem from the browser automatically parsing data on a
page and removing the spam.

> I presume the same would apply if the "Web Services" people came and asked
> to have all of their things included in HTML, and offered a specification
> that could be used to achieve their desires.

It would be the case that they would be subject to the same questions
as the RDFa spec is, yes.

> ...
>
> [not clear what the context was here, so citing as it was]
>>>
>>> > I don't think more metadata is going to improve search engines. In
>>> > practice, metadata is so highly gamed that it cannot be relied upon.
>>> > In fact, search engines probably already "understand" pages with far
>>> > more accuracy than most authors will ever be able to express.
>>>
>>> You are correct, more erroneous metadata is not going to improve search
>>> engines. More /accurate/ metadata, however, IS going to improve search
>>> engines. Nobody is going to argue that the system could not be gamed. I
>>> can guarantee that it will be gamed.
>>>
>>> However, that's the reality that we have to live with when introducing
>>> any new web-based technology. It will be mis-used, abused and corrupted.
>>> The question is, will it do more good than harm? In the case of RDFa
>>> /and/ Microformats, we do think it will do more good than harm.
>>
>> For search engines, I am not convinced. Google's experience is that
>> natural language processing of the actual information seen by the actual
>> end user is far, far more reliable than any source of metadata. Thus from
>> Google's perspective, investing in RDFa seems like a poorer investment
>> than investing in natural language processing.
>
> Indeed. But Google is something of an edge case, since they can afford to
> run a huge organisation with massive computer power and many engineers to
> address a problem where a "near-enough" solution brings themn the users who
> are in turn the product they sell to advertisers. There are many other use
> cases where a small group of people want a way to reliably search trusted
> data.
>
> From global virtual library systems to a single websites, there are many
> others who find that processing structured data is more efficient for their
> needs than doing free-text analysis of web pages (something that they
> effectively contract out to Google, Ask, Yahoo! and their many competitors
> who specialise in it). Some of these are the people whe have decided that
> investing in RDFa is a far more valuable exercis than trying to out-invest
> Google in natural language processing.

"Processing structured data" is something that can be done without
RDFa.  The reason for the resistance to RDFa from this working group
so far is the lack of sufficient significant problems that are best
solved by RDFa specifically.

As well, the use cases for in-the-small data interchange and
in-the-large data interchange are significantly different.  Again,
RDFa is a very distributed data storage format; you don't see the
entire 'database' until you've trawled all the pages which include it.
 This is why there is such a focus on whether RDFa is a decent
solution for search engines - they *see* the web better than anyone
else, and thus appear to be able to utilize such a distributed data
format most effectively than anyone else.  However, Ian is pointing
out that those same search engines (at least Google, though I expect
Yahoo, etc. feel the same) believe that natural-language processing is
a far more effective method of gathering information.  It is less
prone to gaming (natural language being naturally unstructured, it's
harder to emit spam data that has the same statistical
characteristics), and allows for extracting far more data
automatically than any one user would ever think to include.

> This email is already too long for most people to get through it :( I
> believe that this discussion is going to last for some time (I cannot
> imagine why, given the HTML timeline, it would need to be resolved before
> June), so there will be time for others to discuss more fully the many
> points Ian raises as ones he would like to understand.

The HTML timeline is partially a joke (2023 is the date for 'full
compliance'; there isn't a single browser yet who has fully
implemented *html4* ^_^).  We still would like things resolved with
all due speed; the faster they hit the spec, the faster they'll be
integrated into browsers.


Conclusion
==========

There is significant confusion (or at least lack of distinction) in
your email (and generally in the arguments from RDFa supporters in my
experience) between RDFa and RDF, RDF and the general concept of data
interchange formats, distributed and centralized data storage,
in-the-small data interchange and in-the-large data interchange, and
personal use (ie web users) and organization use (ie search engines).
Each of these individually confuse the argument; when brought together
as they typically are, they render many arguments completely useless.

Separating RDFa from RDF
------------------------

The bonuses/maluses of RDF itself are completely irrelevant to this
discussion.  This is because there already exists several methods in
active use for embedding RDF in a web page.  In other words, whatever
problem requires you to embed RDF in a webpage has been *solved*, and
without any necessity of cooperation from the html language itself.
RDFa is specifically a proposal to embed structured data in a web page
using attributes on elements.  *This* is the solution we need to find
problems for if we want RDFa merged into the spec.

Separating RDF from general data interchange formats
----------------------------------------------------

Many of the problems that can be solved by using a common data
interchange format don't require specifically what RDF brings to the
table.  As noted earlier in this email, every collection of data has
its own shape, and its own particular 'ideal' representation.  RDF
forces a particular method of representation.  This has its bonuses
and maluses, but they are *completely separate* from the
bonuses/maluses of generically using a data interchange format.
Libraries don't need RDF to exchange data, they just need *some*
agreement on data representation.  What problems are specifically
solved by RDF and its specific representation being favored in the
spec over a more general method of data representation?

Separating distributed and centralized data storage
----------------------------------------------------

RDFa is a distributed data storage format - a single page includes
only a fraction of the relevant data.  The opposite possibility is
centralized data storage - a single entity holding the data in a
particular place (such as a database on their servers).  The latter is
very common, simple, and natural.  To get at the data, you just run
queries against the single database.  This does require the entity
with the data to produce an API to run queries against, but the same
is required for use of a distributed data format (the company in
charge of the site has to specifically code to expose that data in the
given format).  Both storage methods, though, allow sharing of data
and enable all manner of useful web services.  What problems are
specifically solved by a distributed data strategy which are solved
worse or not at all by a centralized data strategy?

Separating in-the-small and in-the-large data interchange
---------------------------------------------------------

In-the-small data interchange involves a small number of entities who
can trust each other and generally receive a direct benefit from
structuring and sharing their data.  In-the-large data interchange
involves a large number of disparate entities who *can't* trust each
other and won't generally receive direct benefit for structuring their
data.  What problems are shared by these two situations?  Which are
best solved by RDFa?  Are there existing solutions to these problems
that are adequate?

If RDFa is intended to be for one or the other of these situations, it
would be convenient for advocates to agree which it is, so that we can
then focus the discussion on that.  As it is we are getting into
useless arguments where someone is talking about one situation, and
then someone else brings up a "Yes, but..." involving the other
situation.

Separating personal consumption from corporate consumption
----------------------------------------------------------

It has already been noted that existing search engines have found
metadata to be generally unreliable, and instead rely on
natural-language processing to extract information from pages.  Can
RDFa offer better solutions to the problems of search engines than
they currently employ?

Personal use is an entirely different issue.  RDFa is often touted as
making it easy for users to look up information about data on the
page.  It has also been noted, though, that simply highlighting some
text (say, a song title) and selecting "Search Google for the text
'...'" (specific text is from my machine; your experience may vary)
does essentially the same thing, and possibly offers much more.  As
well, new features such as IE8's accelerators offer even more advanced
functionality when you need it, such as allowing you to search
IMBD.com specifically for your highlighted text, using IMDB's own
search form.  Are there significant problems left in this space?  Does
RDFa solve them?  Are they better solved by other solutions?

~TJ


From jackalmage at gmail.com  Fri Jan  2 09:52:35 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 2 Jan 2009 11:52:35 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um38vt1gwxe0ny@widsithpro.lan>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<495D0EB9.3090407@takkaria.org> <op.um38vt1gwxe0ny@widsithpro.lan>
Message-ID: <dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>

On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
<chaals at opera.com> wrote:
> On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell <andi at takkaria.org> wrote:
>
>> On 2009-01-01 15:24, Toby A Inkster wrote:
>>>
>>> The use cases for RDFa are pretty much the same as those for
>>> Microformats.
>>
>> Right, but microformats can be used without any changes to the HTML
>> language, whereas RDFa requires such changes.  If they fulfill the same use
>> cases, then there's not much point in adding RDFa.
>
> ...

Why the non-response?  This is precisely the point of contention.
Things aren't added to the spec on a whim.  Things get added when it
is demonstrated that authors will significantly benefit from the
inclusion of the feature in the language.  Microformats (used as an
example only) use only features already in the language, and thus do
not need any spec support.  If they already solve the problem
adequately, then there is no need to go further.

>>> So why RDFa and not Microformats?
>
> (I think the question should be why RDFa is needed *as well as* ?formats)

This is correct.  Microformats exist already.  They solve current
problems.  Are there further problems that Microformats don't address
which can be solved well by RDFa?  Are these problems significant
enough to authors to be worth addressing in the spec, or can we wait
and let the community work out its own solutions further before we
make a move?  We generally want to wait until a given item is truly
established before speccing it, so that we can work with existing
use-cases and solve known problems.  To do otherwise risks us
inventing use-cases that don't commonly exist in reality, solving
non-problems while leaving gaping holes that will cause authors
problems down the line.

For an example (used several times, but that's because it's a really
good example), consider <video>.  Flash-based video players are
already extremely common.  We know how people use them, we know what
authors generally expect from them, and we know what problems exist
with how they are currently implemented and used.  We also feel that
extending the language would allow us to solve these problems, and
help authors significantly.  Thus, <video>.

Microformats are the metadata equivalent of Flash-based video players.
 They are hacks used to allow authors to accomplish something not
explicitly accounted for in the language.  Are there significant
problems with this approach?  Is metadata embedding used widely enough
to justify extending the language for it, or are the current hacks
(Microformats, in this case) enough?  Are current metadata embedding
practices mature enough that we can be relatively sure we're solving
actual problems with our extension?  These are all questions that must
be asked of any extention to the language.

>>> Firstly, RDFa provides a single unified parsing algorithm that
>>> Microformats do not. ...
>
>> This is not necessarily beneficial.  If you have separate parsing
>> algorithms, you can code in shortcuts for common use-cases and thus optimise
>> the authoring experience.
>
> On the other hand, you cannot parse information until you know how it is
> encoded, and information encoded in RDFa can be parsed without knowing more.
>
> And not only can you optimise your parsing for a given algorithm, you can
> also do for a known vocabulary - or you can optimise the post-parsing
> treatment.

What is the benefit to authors of having an easily machine-parsed
format?  (Note: this is completely separate from the question of the
benefits of metadata at all.)  Are they greater than the benefits of a
format that is harder to parse, but easier for authors to write?

>
>>  Also, as has been pointed out before in the distributed extensibility
>> debate, parsing is a very small part of doing useful things with content.
>
> Yes. However many of the use cases that I think justify the inclusion of
> RDFa are already very small on their own, and valuable when several
> vocabularies are combined. So being able to do off-the-shelf parsing is
> valuable, compared to working out how to parse a combination of formats
> together.

Can you provide these use-cases?  The discussion has an astonishing
dearth of use-cases by which we can evaluate the effectiveness of
proposals.

>>> Secondly, as the result of having one single parsing algorithm,
>>> decentralised development is possible. If I want a way of marking up my
>>> iguana collection semantically, I can develop that vocabulary without
>>> having to go through a central authority.
>>
>> You can develop vocabularies without going through a central authority
>> already, via class or id, and many people already do.
>>
>>> Because URIs are used to
>>> identify vocabulary terms, I can be sure that my vocabulary won't clash
>>> with other people's vocabularies.
>>
>> Again, you can do this with class, by putting your domain name in the
>> class attribute.  It also depends on how much of an issue you think clashes
>> will be with an iguana collection-- I would suggest that due to the
>> specialised nature of the markup, clashes would be quite unlikely.
>
> It depends how many people work on iguana collections - or Old Norse and
> Anglo Saxon text, which was the use case that got me involved in the Web in
> the very early 90s. It turns out that people don't, in the ?formats world,
> use unambiguous names, especially when they are privately developing their
> own information. By contrast, those who come from an RDF world do this by
> habit.

Is this a problem that needs to be solved in the spec, or is it one
that can be solved socially?  More importantly, is it a problem that
needs to be solved at all?  Is there any indication that use of
ambiguous names produces significant problems for authors?

>>> It can be argued that going through a
>>> community to develop vocabularies is beneficial, as it allows the
>>> vocabulary to be built by "many minds" - RDFa does not prevent this, it
>>> just gives people alternatives to community development.
>>
>> RDFa does not give anything over what the class attribute does in terms of
>> community vs individual development, so this doesn't really speak in RDFa's
>> favour.
>
> In principle no, but in real world usage the class attribute is considered
> something that is primarily local, whereas RDFa is generally used by people
> who have a broader outlook on the desirable permanence and re-usability of
> their data.

Can we extract a requirement from this, then?

>>> Lastly, there are a lot of parsing ambiguities for many Microformats.
>>> One area which is especially fraught is that of scoping. The editors of
>>> many current draft Microformats[1] would like to allow page authors to
>>> embed licensing data - e.g. to say that a particular recipe for a pie is
>>> licensed under a Creative Commons licence. However, it has been noted
>>> that the current rel=license Microformat can not be re-used within these
>>> drafts, because virtually all existing rel=license implementations will
>>> just assume that the license applies to the whole page rather than just
>>> part of it. RDFa has strong and unambiguous rules for scoping - a
>>> license, for example, could apply to a section of the page, or one
>>> particular image.
>>
>> Are there other cases where this granularity of scoping would be genuinely
>> helpful?  If not, it would seem better to work out a solution for scoping
>> licence information...
>
> Yes.
>
> Being able to describe accessibility of various parts of content, or point
> to potential replacement content for particular use cases, benefits
> enormously from such scoping (this is why people who do industrial-scale
> accessibility often use RDF as their infrastructure). ARIA has already taken
> the approach of looking for a special-purpose way to do this, which
> significantly bloats HTML but at least allows important users to satisfy
> their needs to be able t produce content with certain information included.
>
> Government and large enterprises produce content that needs to be
> maintained, and being able to include production, cataloguing, and similar
> metadata directly, scoped to the document, would be helpful. As a trivial
> example, it would be useful to me in working to improve the Web content we
> produce at Opera to have a nice mechanism for identifying the original
> source of various parts of a page.

Can we distill this into use-cases, then?  You, as an author, want to
be able to specify the original source of a piece of content.  What's
the practical use of this?  Does it require an embedded,
machine-readable vocabulary to function?  Are existing solutions
adequate (frex, footnotes)?

>> What would you do with scoped copyright information, anyway?  I can see
>> images being an issue, but ideally information about a resource should be
>> kept in that resource, and as such the licence should be embedded in the
>> image rather than given by a Web page.  In the case of particular sections
>> having particular licences, is there any practical use of marking up
>> different sections with different licences over just doing that with text?
>
> Mash-ups. If they have a use-case, and I think it is widely accepted that
> they do, then it would seem obvious that being able to identify the source
> of each part, and any conditions that vary between different sources, is a
> use case.

Not quite.  Specifically, is there any practical use for marking up
various sections of a site with licensing information specific to that
section *in an embedded, machine-readable manner*?  Are the existing
solutions adequate (frex, simply putting a separate copyright notice
on each section, or noting the various copyrights on a licensing
page)?

(Note: I responded to your email rather than the OP because it
presented better points to respond to.)

~TJ


From julian.reschke at gmx.de  Fri Jan  2 09:55:55 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 02 Jan 2009 18:55:55 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
Message-ID: <495E552B.5070004@gmx.de>

Tab Atkins Jr. wrote:
> ...
> Solutions for this already exist; embedded N3 in a <script> tag, just
> to name something that Ian already mentioned, allows you to mash RDF
> data into a page in a machine-extractable way, and brings in any of
> the specific ancillary benefits of RDF.
> ...

Well, it'll require an N3 parser where previously none was needed. Also, 
it separates the metadata from the text, a situation most people want to 
avoid.

This may work, but as far as I can tell, the use of <script> for "data 
blocks" is an afterthought -- for instance, it's described in a section 
about, well, Scripting.

So, is anybody using this successfully in practice?

> ...
> Not quite correct.  Again, the problem of embedded shareable data in a
> web page has been solved multiple times.  The specific problem of
> sharing *RDF* data (due to needing/wanting the specific benefits RDF
> can offer) has also been solved.  What are the precise problems that
> require *RDFa* as a solution?
> ...

Could you elaborate a bit on these solutions?

My understanding was that RDFa has been produced in order to address 
problems with other approaches, such as using <meta> elements, eRDF, or 
microformats.

If there is a *successful* alternative to RDFa that does not require new 
attributes, please let us know :-).

> ...
> Well, there are many things that would offer more advantages than
> disadvantages by themselves.  We can't possibly include all of them in
> the spec; you can think about this as including a hidden large
> disadvantage of 'will grow the size of the spec and the amount of work
> implementors have to do'.  Thus the advantages must generally be
> significantly larger than the disadvantages; this is why the best
> argument for including something in the spec is often "there are
> already widespread hacks to accomplish this".  <video>, for example,
> was included based on pretty much precisely that argument.
> ...

Reminder: RDFa is one of the things the (W3C) Working Group's Charter 
mentions as candidate for inclusion (either by a generic extensibility 
mechanism, or otherwise by extending the language):

"The HTML WG is encouraged to provide a mechanism to permit 
independently developed vocabularies such as Internationalization Tag 
Set (ITS), Ruby, and RDFa to be mixed into HTML documents." 
<http://www.w3.org/2007/03/HTML-WG-charter.html#other>

 > ...

Best regards, Julian


From julian.reschke at gmx.de  Fri Jan  2 10:02:44 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 02 Jan 2009 19:02:44 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>	<495D0EB9.3090407@takkaria.org>
	<op.um38vt1gwxe0ny@widsithpro.lan>
	<dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
Message-ID: <495E56C4.5040207@gmx.de>

Tab Atkins Jr. wrote:
>>> Right, but microformats can be used without any changes to the HTML
>>> language, whereas RDFa requires such changes.  If they fulfill the same use
>>> cases, then there's not much point in adding RDFa.
>> ...
> 
> Why the non-response?  This is precisely the point of contention.
> Things aren't added to the spec on a whim.  Things get added when it
> is demonstrated that authors will significantly benefit from the
> inclusion of the feature in the language.  Microformats (used as an
> example only) use only features already in the language, and thus do
> not need any spec support.  If they already solve the problem
> adequately, then there is no need to go further.
> ...

I think the supporters of RDFa (me included) claim that Microformats 
only address a subset of the problem solved by RDFa.

>>>> So why RDFa and not Microformats?
>> (I think the question should be why RDFa is needed *as well as* ?formats)
> 
> This is correct.  Microformats exist already.  They solve current
> problems.  Are there further problems that Microformats don't address
> which can be solved well by RDFa?  Are these problems significant
> enough to authors to be worth addressing in the spec, or can we wait
> and let the community work out its own solutions further before we
> make a move?  We generally want to wait until a given item is truly
> established before speccing it, so that we can work with existing

Oh really? That's news to me.

If this is principle we agree on that we really should start cutting 
lots of things from the spec.

> ...


Best regards, Julian


From jackalmage at gmail.com  Fri Jan  2 10:29:21 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 2 Jan 2009 12:29:21 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495E552B.5070004@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
	<495E552B.5070004@gmx.de>
Message-ID: <dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>

On Fri, Jan 2, 2009 at 11:55 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Tab Atkins Jr. wrote:
>>
>> ...
>> Solutions for this already exist; embedded N3 in a <script> tag, just
>> to name something that Ian already mentioned, allows you to mash RDF
>> data into a page in a machine-extractable way, and brings in any of
>> the specific ancillary benefits of RDF.
>> ...
>
> Well, it'll require an N3 parser where previously none was needed.

RDFa requires an RDFa parser as well, and in general *any* metadata
requires a parser, so this point is moot.  The only metadata that
doesn't require a parser is no metadata at all.

> Also, it
> separates the metadata from the text, a situation most people want to avoid.

That sounds like a requirement, but it's one that already presumes
that metadata is useful to embed in webpages.  It has not yet been
established that there is a problem worth solving that metadata would
address at all.  (Clarifying this was the primary purpose of Ian's
mail, and my first mail in this thread.)

> This may work, but as far as I can tell, the use of <script> for "data
> blocks" is an afterthought -- for instance, it's described in a section
> about, well, Scripting.
>
> So, is anybody using this successfully in practice?

I have no idea.  The point is, though, that it *is* an existing
possibility that requires no further effort from this working group or
browser developers.  As such, if it solves the problem (whatever it
is, since that hasn't yet been well-established) sufficiently, we can
leave it alone.  It is in the best interests of everybody if a
solution can be found without any changes to the language, because it
means browser uptake is quick (immediate and retroactive, to be
precise ^_^).

We have to ensure that the problem isn't already solved by the
language first, and only after that can we evaluate whether the
language is the correct place to solve the problem, and only after
*that* can we start discussing how to actually go about solving the
problem in the language.  Too much of this discussion is jumping
straight to step 3, so Ian, I, and others are trying to focus it on
step 1.

>> ...
>> Not quite correct.  Again, the problem of embedded shareable data in a
>> web page has been solved multiple times.  The specific problem of
>> sharing *RDF* data (due to needing/wanting the specific benefits RDF
>> can offer) has also been solved.  What are the precise problems that
>> require *RDFa* as a solution?
>> ...
>
> Could you elaborate a bit on these solutions?

Microformats, embedded data in <script> blocks, embedded XML, custom
attributes, other miscellaneous uses of @class and related attributes,
and simply putting the data in natural language.

These solutions already exist, and in several cases are easier to use
than RDFa.  Do they have specific failings that RDFa addresses?  Are
these failings significant enough to warrant extending the language to
solve them?  To we *understand* the failings (assuming they exist and
are significant) well enough to be confident we can solve them
correctly in the language, rather than waiting for the community to
solve them themselves and then simply reifying their solutions?

> My understanding was that RDFa has been produced in order to address
> problems with other approaches, such as using <meta> elements, eRDF, or
> microformats.
>
> If there is a *successful* alternative to RDFa that does not require new
> attributes, please let us know :-).

The most successful alternative is nothing at all.  ^_^  We can
extract copious data from web pages reliably without metadata, either
using our human senses (in personal use) or natural-language-based
processing (in search engine use).  It has not yet been established
that sufficient and significant enough problems *exist* to justify a
solution, let alone one that requires an addition to html.  That is
what Ian is specifically looking for.

Unfortunately, you really do need to justify metadata anew; you can't
just point at Microformats or something similar and say "we're doing
the same things as those guys!".  They exist currently because they
can fit their solutions into the language as it is; there is no
further need to justify them in this group.  Modifying the language,
though, is an explicit admission that this is a problem worth solving
and worth solving in a particular way, and so requires significant
justification.

>> ...
>> Well, there are many things that would offer more advantages than
>> disadvantages by themselves.  We can't possibly include all of them in
>> the spec; you can think about this as including a hidden large
>> disadvantage of 'will grow the size of the spec and the amount of work
>> implementors have to do'.  Thus the advantages must generally be
>> significantly larger than the disadvantages; this is why the best
>> argument for including something in the spec is often "there are
>> already widespread hacks to accomplish this".  <video>, for example,
>> was included based on pretty much precisely that argument.
>> ...
>
> Reminder: RDFa is one of the things the (W3C) Working Group's Charter
> mentions as candidate for inclusion (either by a generic extensibility
> mechanism, or otherwise by extending the language):
>
> "The HTML WG is encouraged to provide a mechanism to permit independently
> developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and
> RDFa to be mixed into HTML documents."
> <http://www.w3.org/2007/03/HTML-WG-charter.html#other>

As a note, this isn't the W3C's HTML WG.  The WHATWG is independent
from the W3C.

~TJ


From jackalmage at gmail.com  Fri Jan  2 11:14:46 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 2 Jan 2009 13:14:46 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495E56C4.5040207@gmx.de>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<495D0EB9.3090407@takkaria.org> <op.um38vt1gwxe0ny@widsithpro.lan>
	<dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
	<495E56C4.5040207@gmx.de>
Message-ID: <dd0fbad0901021114v77183e14lf02505f55c2ab038@mail.gmail.com>

On Fri, Jan 2, 2009 at 12:02 PM, Julian Reschke <julian.reschke at gmx.de> wrote:
> Tab Atkins Jr. wrote:
>>>>
>>>> Right, but microformats can be used without any changes to the HTML
>>>> language, whereas RDFa requires such changes.  If they fulfill the same
>>>> use
>>>> cases, then there's not much point in adding RDFa.
>>>
>>> ...
>>
>> Why the non-response?  This is precisely the point of contention.
>> Things aren't added to the spec on a whim.  Things get added when it
>> is demonstrated that authors will significantly benefit from the
>> inclusion of the feature in the language.  Microformats (used as an
>> example only) use only features already in the language, and thus do
>> not need any spec support.  If they already solve the problem
>> adequately, then there is no need to go further.
>> ...
>
> I think the supporters of RDFa (me included) claim that Microformats only
> address a subset of the problem solved by RDFa.

The next step, then, is to list these problems, establish that they
truly aren't solved by existing solutions (not just Microformats),
establish that solving them would be of significant benefit to
authors, and finally that solving them within HTML is the most
appropriate course of action.

>>>>> So why RDFa and not Microformats?
>>>
>>> (I think the question should be why RDFa is needed *as well as* ?formats)
>>
>> This is correct.  Microformats exist already.  They solve current
>> problems.  Are there further problems that Microformats don't address
>> which can be solved well by RDFa?  Are these problems significant
>> enough to authors to be worth addressing in the spec, or can we wait
>> and let the community work out its own solutions further before we
>> make a move?  We generally want to wait until a given item is truly
>> established before speccing it, so that we can work with existing
>
> Oh really? That's news to me.
>
> If this is principle we agree on that we really should start cutting lots of
> things from the spec.

It is a general principle, though not a necessary one.  As Ian noted
in his earlier email, speccing a solution too early runs the risk of
solving the wrong problem, and then poisoning that area of the
solution space entirely.  If we wait for authors to develop their own
hacks around features missing in the language, we can be sure that
we're solving a problem authors want solved, and we have some measure
of implementation experience already (even if just in author-deployed
Javascript) that we can learn from.  Other groups use this principle
as well - browser vendors prefix their early versions of new CSS
properties, for example, so that authors using these early versions
don't poison the space and prevent problems from being addressed that
would 'break' uses of the property.

Most the additions in HTML5 are designed on this principle.  For
example, the <video> element and the additional values for <input> are
drawn directly from javascript and flash-based solutions currently in
use, with the intent to make them easier for authors to use.  Others,
such as the additional sectioning elements and the new header-parsing
algorithm, were meant to embrace and bless well-established authoring
practices (splitting your content into header, footer, and content
<div>s, or building documents from smaller fragments which use <h1>
and such with clear intent to create a .  Finally, some additions (the
Workers spec, the SQL spec) have little in the way of current-practice
analogues (though much of those things are presaged in Gears, frex)
because they are designed to specifically address a current lack and
enable future uses.  These, though, still solve well-defined problems
and bring benefits which significantly outweigh their downsides.

RDFa isn't a well-established authoring pattern needing to be blessed
and made explicit.  That means it's either a simplification of
existing widespread hacks (Microformats?) intended to make authors
lives easier, or it's intended to fill a gaping hole that can be
established to be of significant benefit to authors to have filled.
Either way, one needs some justification.

Frex, it's possible that the language *could* be extended to make
Microformat-type things easier to use for authors.  We'd need to
establish that Microformats (or some other embedded metadata) really
are commonly used, though, and that the proposed simplification is
really significant enough (existing validation and video libraries,
for example, are much more complex to use than <input type="email"> or
<video>, and can impose significant extra bandwidth costs which are
undesirable).

It's also possible that embedded metadata support *is* a gaping hole
that needs to be filled.  We'd still need to (a) establish the problem
clearly (so we can evaluate possible solutions) and (b) decide that
RDFa is a good solution to the problem as stated before we add it into
the language.

~TJ


From list at asbjorn.ulsberg.no  Fri Jan  2 13:53:06 2009
From: list at asbjorn.ulsberg.no (=?iso-8859-15?Q?Asbj=F8rn_Ulsberg?=)
Date: Fri, 02 Jan 2009 22:53:06 +0100
Subject: [whatwg] Issues relating to the syntax of dates and times
In-Reply-To: <Pine.LNX.4.62.0811261003160.17401@hixie.dreamhostps.com>
References: <mailman.32271.1227616787.20699.whatwg-whatwg.org@lists.whatwg.org>
	<C223ED588D01490BA9111CBB533E8B0A@Sanktum01>
	<dd0fbad0811250644y5e6b02f7je35ef7475f4a477f@mail.gmail.com>
	<046924091C524D728B5A52EAB3E389B0@Sanktum01>
	<Pine.LNX.4.62.0811252050470.17401@hixie.dreamhostps.com>
	<D222ACB840DB4BC1B5361F33CF3163F2@Sanktum01>
	<Pine.LNX.4.62.0811252128570.17401@hixie.dreamhostps.com>
	<B7E37EE452A740F2B5439C2E4F3FC290@Sanktum01>
	<Pine.LNX.4.62.0811252216490.17401@hixie.dreamhostps.com>
	<F5EB1CEED3B249C0875B2EA1AB17C0CC@Sanktum01>
	<Pine.LNX.4.62.0811261003160.17401@hixie.dreamhostps.com>
Message-ID: <op.um5ge6jnflu5h5@quark-mac-pro.local>

On Wed, 26 Nov 2008 11:09:24 +0100, Ian Hickson <ian at hixie.ch> wrote:

> The spec draws the line already -- it says that the date has to be in the
> proleptic Gregorian calendar, and that the year has to be greater than
> zero.

Reading the spec, I have to wonder: Does HTML5 need to specify as much as it does inline? Can't more of it be referenced to ISO 8601 or even better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date constructs: 

<http://www.atompub.org/rfc4287.html#date.constructs>

Does not RFC 3339 defined date and time in a satisfactory manner to use directly in HTML5? If there's prior discussion regarding this, I'd really appreciate a pointer. Thanks!

-- 
Asbj?rn Ulsberg         -=|=-          asbjorn at ulsberg.no
?He's a loathsome offensive brute, yet I can't look away?




From 111mth at gmail.com  Fri Jan  2 14:39:41 2009
From: 111mth at gmail.com (111mth at gmail.com)
Date: Fri, 02 Jan 2009 22:39:41 +0000
Subject: [whatwg] =?utf-8?q?Minor_error_in_content=E2=80=90type_sniffing_t?=
	=?utf-8?q?able?=
In-Reply-To: <495A8F46.5080803@gmail.com>
References: <49587835.1030701@gmail.com> <495A8F46.5080803@gmail.com>
Message-ID: <495E97AD.30301@gmail.com>

An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090102/3e877cc0/attachment.htm>

From foolistbar at googlemail.com  Fri Jan  2 15:06:01 2009
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Fri, 2 Jan 2009 23:06:01 +0000
Subject: [whatwg]
 =?utf-8?q?Minor_error_in_content=E2=80=90type_sniffing_t?=
 =?utf-8?q?able?=
In-Reply-To: <495E97AD.30301@gmail.com>
References: <49587835.1030701@gmail.com> <495A8F46.5080803@gmail.com>
	<495E97AD.30301@gmail.com>
Message-ID: <0ED82603-A4CF-4B64-9C0F-AD577BC56A92@googlemail.com>


On 2 Jan 2009, at 22:39, 111mth at gmail.com wrote:

> In section 2.7.4 of the specification, part of the table reads
> FF FF 00 00
> FE FF 00 00
> text/plain
> n/a
> UTF-16BE BOM
> FF FF 00 00
> FF FF 00 00
> text/plain
> n/a
> UTF-16LE BOM
> in the 1 January draft.
>
> Should this be
> FF FF 00 00
> FE FF 00 00
> text/plain
> n/a
> UTF-16BE BOM
> FF FF 00 00
> FF FE 00 00
> text/plain
> n/a
> UTF-16LE BOM
> ?

Yes.


--
Geoffrey Sneddon



From foolistbar at googlemail.com  Fri Jan  2 15:07:34 2009
From: foolistbar at googlemail.com (Geoffrey Sneddon)
Date: Fri, 2 Jan 2009 23:07:34 +0000
Subject: [whatwg] Issues relating to the syntax of dates and times
In-Reply-To: <op.um5ge6jnflu5h5@quark-mac-pro.local>
References: <mailman.32271.1227616787.20699.whatwg-whatwg.org@lists.whatwg.org>
	<C223ED588D01490BA9111CBB533E8B0A@Sanktum01>
	<dd0fbad0811250644y5e6b02f7je35ef7475f4a477f@mail.gmail.com>
	<046924091C524D728B5A52EAB3E389B0@Sanktum01>
	<Pine.LNX.4.62.0811252050470.17401@hixie.dreamhostps.com>
	<D222ACB840DB4BC1B5361F33CF3163F2@Sanktum01>
	<Pine.LNX.4.62.0811252128570.17401@hixie.dreamhostps.com>
	<B7E37EE452A740F2B5439C2E4F3FC290@Sanktum01>
	<Pine.LNX.4.62.0811252216490.17401@hixie.dreamhostps.com>
	<F5EB1CEED3B249C0875B2EA1AB17C0CC@Sanktum01>
	<Pine.LNX.4.62.0811261003160.17401@hixie.dreamhostps.com>
	<op.um5ge6jnflu5h5@quark-mac-pro.local>
Message-ID: <9331EC4D-9508-4F97-A41A-2211450E9AB5@googlemail.com>


On 2 Jan 2009, at 21:53, Asbj?rn Ulsberg wrote:

> On Wed, 26 Nov 2008 11:09:24 +0100, Ian Hickson <ian at hixie.ch> wrote:
>
>> The spec draws the line already -- it says that the date has to be  
>> in the
>> proleptic Gregorian calendar, and that the year has to be greater  
>> than
>> zero.
>
> Reading the spec, I have to wonder: Does HTML5 need to specify as  
> much as it does inline? Can't more of it be referenced to ISO 8601  
> or even better; RFC 3339? I really fancy how Atom (RFC 4287) has  
> defined date constructs:
> <http://www.atompub.org/rfc4287.html#date.constructs>
>
> Does not RFC 3339 defined date and time in a satisfactory manner to  
> use directly in HTML5? If there's prior discussion regarding this,  
> I'd really appreciate a pointer. Thanks!

Without looking up prior discussion, the short answer is that content  
relies upon the parsing currently specified. Also, neither RFC3339 nor  
ISO8601 define parsing.


--
Geoffrey Sneddon
<http://gsnedders.com/>



From webmartians at verizon.net  Fri Jan  2 16:29:09 2009
From: webmartians at verizon.net (WeBMartians)
Date: Fri, 02 Jan 2009 19:29:09 -0500
Subject: [whatwg] Issues relating to the syntax of dates and times
In-Reply-To: <op.um5ge6jnflu5h5@quark-mac-pro.local>
References: <mailman.32271.1227616787.20699.whatwg-whatwg.org@lists.whatwg.org>
	<C223ED588D01490BA9111CBB533E8B0A@Sanktum01>
	<dd0fbad0811250644y5e6b02f7je35ef7475f4a477f@mail.gmail.com>
	<046924091C524D728B5A52EAB3E389B0@Sanktum01>
	<Pine.LNX.4.62.0811252050470.17401@hixie.dreamhostps.com>
	<D222ACB840DB4BC1B5361F33CF3163F2@Sanktum01>
	<Pine.LNX.4.62.0811252128570.17401@hixie.dreamhostps.com>
	<B7E37EE452A740F2B5439C2E4F3FC290@Sanktum01>
	<Pine.LNX.4.62.0811252216490.17401@hixie.dreamhostps.com>
	<F5EB1CEED3B249C0875B2EA1AB17C0CC@Sanktum01>
	<Pine.LNX.4.62.0811261003160.17401@hixie.dreamhostps.com>
	<op.um5ge6jnflu5h5@quark-mac-pro.local>
Message-ID: <559F6629BB864D05893E9CDCCF41DD29@pirate>

Asbj?rn, while I can't give you a message-list, please believe me when I say that the HTML5 specifications on this are the result of
quite a bit of discussion and IMHO represent a reasonable compromise between driving the developers crazy and supporting dates and
times back to the Cenozoic era.

That said, I'm staying out of this one! ...been here too many times already...
-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Asbj?rn Ulsberg
Sent: Friday, 2009 January 02 16:53
To: Ian Hickson
Cc: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Issues relating to the syntax of dates and times

On Wed, 26 Nov 2008 11:09:24 +0100, Ian Hickson <ian at hixie.ch> wrote:

> The spec draws the line already -- it says that the date has to be in 
> the proleptic Gregorian calendar, and that the year has to be greater 
> than zero.

Reading the spec, I have to wonder: Does HTML5 need to specify as much as it does inline? Can't more of it be referenced to ISO 8601
or even better; RFC 3339? I really fancy how Atom (RFC 4287) has defined date constructs: 

<http://www.atompub.org/rfc4287.html#date.constructs>

Does not RFC 3339 defined date and time in a satisfactory manner to use directly in HTML5? If there's prior discussion regarding
this, I'd really appreciate a pointer. Thanks!

-- 
Asbj?rn Ulsberg         -=|=-          asbjorn at ulsberg.no
?He's a loathsome offensive brute, yet I can't look away?





From ian at hixie.ch  Fri Jan  2 19:47:11 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 3 Jan 2009 03:47:11 +0000 (UTC)
Subject: [whatwg] The FAQ and other information
In-Reply-To: <495E56C4.5040207@gmx.de>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<495D0EB9.3090407@takkaria.org> <op.um38vt1gwxe0ny@widsithpro.lan>
	<dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
	<495E56C4.5040207@gmx.de>
Message-ID: <Pine.LNX.4.62.0901030318480.25317@hixie.dreamhostps.com>


With the new year I thought I'd take the opportunity to remind everyone of 
some of our community's resources:

   The FAQ - http://wiki.whatwg.org/wiki/FAQ
   This contains many replies to common questions about process, 
   timetable, and about common topics of discussion. I recommend it to 
   anyone who has not read it recently, as it can be good to have a 
   refresher about the basics occasionally.

   The Blog - http://blog.whatwg.org/
   Anyone is open to post on the WHATWG blog, so if you have something 
   about HTML5 or the WHATWG to say, feel free to write it. It can even be 
   controversial, if you so desire! Mark Pilgrim has been doing a great 
   series on what's going on, "this week in HTML5", so if you are having 
   trouble following the mailing list this is a good one to follow too.

   IRC -- #whatwg on Freenode
   We often talk about random things on IRC, feel free to join in.

   Forums - http://forums.whatwg.org/
   If you prefer forums, feel free to participate here.


To track the progress of the group, you can follow our Twitter feed or 
subscript to the relevant mailing list:

   http://twitter.com/WHATWG
   http://www.whatwg.org/mailing-list#commits

The recent changes are also listed at:

   http://html5.org/tools/web-apps-tracker

This tool also lets you filter the list by how important the change was 
and who was affected.

The list of pending e-mails is online at:

   http://www.whatwg.org/issues/

A graph showing progress towards zero e-mails is also available:

   http://www.whatwg.org/issues/


As a reminder we are also working in conjunction with the W3C's HTML 
working group, information on which can be found at:

   http://www.w3.org/html/wg/



On Fri, 2 Jan 2009, Julian Reschke wrote:
> > 
> > We generally want to wait until a given item is truly established 
> > before speccing it, so that we can work with existing [...]
> 
> Oh really? That's news to me.

It's in the FAQ:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F


> If this is principle we agree on that we really should start cutting 
> lots of things from the spec.

Yes -- please do bring up things that need to be cut. This is also 
mentioned in the FAQ:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_removing_bad_ideas_from_the_spec.3F

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From julian.reschke at gmx.de  Sat Jan  3 05:02:50 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Sat, 03 Jan 2009 14:02:50 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>	<495E552B.5070004@gmx.de>
	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
Message-ID: <495F61FA.50405@gmx.de>

Tab Atkins Jr. wrote:
> ...
>> Well, it'll require an N3 parser where previously none was needed.
> 
> RDFa requires an RDFa parser as well, and in general *any* metadata
> requires a parser, so this point is moot.  The only metadata that
> doesn't require a parser is no metadata at all.

With RDFa, most of the parsing is done by HTML. So I would call it an 
"RDFa processor". And yes, that doesn't change the fact that code needs 
to be written. But it affects the type of the code that needs to be written.

> ...
> I have no idea.  The point is, though, that it *is* an existing
> possibility that requires no further effort from this working group or
> browser developers.  As such, if it solves the problem (whatever it
> is, since that hasn't yet been well-established) sufficiently, we can
> leave it alone.  It is in the best interests of everybody if a
> solution can be found without any changes to the language, because it
> means browser uptake is quick (immediate and retroactive, to be
> precise ^_^).
> ...

Well, there are lots of conditionals in this statement :-)

> We have to ensure that the problem isn't already solved by the
> language first, and only after that can we evaluate whether the
> language is the correct place to solve the problem, and only after
> *that* can we start discussing how to actually go about solving the
> problem in the language.  Too much of this discussion is jumping
> straight to step 3, so Ian, I, and others are trying to focus it on
> step 1.

I would say this is because the research and design in this area totally 
predates HTML5. Are you seriously suggesting that all of that needs to 
start from scratch?

>>> ...
>>> Not quite correct.  Again, the problem of embedded shareable data in a
>>> web page has been solved multiple times.  The specific problem of
>>> sharing *RDF* data (due to needing/wanting the specific benefits RDF
>>> can offer) has also been solved.  What are the precise problems that
>>> require *RDFa* as a solution?
>>> ...
>> Could you elaborate a bit on these solutions?
> 
> Microformats, embedded data in <script> blocks, embedded XML, custom
> attributes, other miscellaneous uses of @class and related attributes,
> and simply putting the data in natural language.
> ...

- Microformats: how do they solve sharing RDF data?

- embedded data in <script>: see discussion above

- embedded XML: embedded in where?

- custom attributes: wow, that sounds like RDFa

- @class and friends: that sounds like eRDF, which the way it is 
currently specified is broken in HTML5 (@profile)

- natural language: hey great, please elaborate :-)

> ...
>> My understanding was that RDFa has been produced in order to address
>> problems with other approaches, such as using <meta> elements, eRDF, or
>> microformats.
>>
>> If there is a *successful* alternative to RDFa that does not require new
>> attributes, please let us know :-).
> 
> The most successful alternative is nothing at all.  ^_^  We can
> extract copious data from web pages reliably without metadata, either
> using our human senses (in personal use) or natural-language-based
> processing (in search engine use).  It has not yet been established
> that sufficient and significant enough problems *exist* to justify a
> solution, let alone one that requires an addition to html.  That is
> what Ian is specifically looking for.

That's what you and Ian claim. Many disagree.

> Unfortunately, you really do need to justify metadata anew; you can't
> just point at Microformats or something similar and say "we're doing
> the same things as those guys!".  They exist currently because they
> can fit their solutions into the language as it is; there is no
> further need to justify them in this group.  Modifying the language,
> though, is an explicit admission that this is a problem worth solving
> and worth solving in a particular way, and so requires significant
> justification.

Disagreed.

The very existence of Microformats prove that people want to augment 
their content with metadata that is machine-readable. Some of the 
shortcomings of Microformats are caused by the way they are retrofitted 
into HTML. So it's totally natural to discuss whether a better solution 
can be reached by adding new stuff to the language.

>>> ...
>> Reminder: RDFa is one of the things the (W3C) Working Group's Charter
>> mentions as candidate for inclusion (either by a generic extensibility
>> mechanism, or otherwise by extending the language):
>>
>> "The HTML WG is encouraged to provide a mechanism to permit independently
>> developed vocabularies such as Internationalization Tag Set (ITS), Ruby, and
>> RDFa to be mixed into HTML documents."
>> <http://www.w3.org/2007/03/HTML-WG-charter.html#other>
> 
> As a note, this isn't the W3C's HTML WG.  The WHATWG is independent
> from the W3C.
 > ...

Sounds like we need to restart the thread on the HTML WG's mailing list 
then.

Best regards, Julian


From danbri at danbri.org  Sat Jan  3 07:05:22 2009
From: danbri at danbri.org (Dan Brickley)
Date: Sat, 03 Jan 2009 16:05:22 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F61FA.50405@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>	<495E552B.5070004@gmx.de>	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de>
Message-ID: <495F7EB2.2070805@danbri.org>

On 3/1/09 14:02, Julian Reschke wrote:
> Tab Atkins Jr. wrote:
>> ...
>>> Well, it'll require an N3 parser where previously none was needed.
>>
>> RDFa requires an RDFa parser as well, and in general *any* metadata
>> requires a parser, so this point is moot. The only metadata that
>> doesn't require a parser is no metadata at all.
>
> With RDFa, most of the parsing is done by HTML. So I would call it an
> "RDFa processor". And yes, that doesn't change the fact that code needs
> to be written. But it affects the type of the code that needs to be
> written.

Somewhat of an aside, but for the curious - here is an RDFa 
parser/processor app:

http://code.google.com/p/rdfquery/wiki/Introduction
example: http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html
js: http://rdfquery.googlecode.com/svn/trunk/jquery.rdfa.js

[...]

>> The most successful alternative is nothing at all. ^_^ We can
>> extract copious data from web pages reliably without metadata, either
>> using our human senses (in personal use) or natural-language-based
>> processing (in search engine use). It has not yet been established
>> that sufficient and significant enough problems *exist* to justify a
>> solution, let alone one that requires an addition to html. That is
>> what Ian is specifically looking for.
>
> That's what you and Ian claim. Many disagree.

My main problem with the natural language processing option is that it 
feels too close to waiting for Artificial Intelligence. I'd rather add 6 
attributes to HTML and get on with life.

But perhaps a more practical concern is that it unfairly biases things 
towards popular languages - lucky English, lucky Spanish, etc., and 
those that lend themselves more to NLP analysis. The Web is for 
everyone, and people shouldn't be forced to read and write English to 
enjoy the latest advances in Web automation. Since HTML5 is going 
through W3C, such considerations need to be taken pretty seriously.

>> As a note, this isn't the W3C's HTML WG. The WHATWG is independent
>> from the W3C.

But the WHATWG HTML5 *work* is no longer entirely independent of W3C; 
the two organizations embarked on a major joint venture. It seems 
reasonable for members of the WHATWG world to take W3C-oriented 
considerations seriously, regardless of mailing list.

cheers,

Dan

--
http://danbri.org/


From howcome at opera.com  Sat Jan  3 07:54:18 2009
From: howcome at opera.com (=?iso-8859-1?Q?H=E5kon?= Wium Lie)
Date: Sat, 3 Jan 2009 16:54:18 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F7EB2.2070805@danbri.org>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
	<495E552B.5070004@gmx.de>
	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de> <495F7EB2.2070805@danbri.org>
Message-ID: <18783.35370.202167.366672@opera.com>

Also sprach Dan Brickley:

 > My main problem with the natural language processing option is that it 
 > feels too close to waiting for Artificial Intelligence. I'd rather add 6 
 > attributes to HTML and get on with life.

:-)

Personally, I think the 'class' attribute may still be a more
compelling option in a less-is-more way. It already exists and can
easily be used for styling purposes. Styling is bait for authors to
disclose semantics.

Cheers,

-h&kon
              H?kon Wium Lie                          CTO ??e??
howcome at opera.com                  http://people.opera.com/howcome


From danbri at danbri.org  Sat Jan  3 08:11:39 2009
From: danbri at danbri.org (Dan Brickley)
Date: Sat, 03 Jan 2009 17:11:39 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <18783.35370.202167.366672@opera.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>	<495E552B.5070004@gmx.de>	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>	<495F61FA.50405@gmx.de>	<495F7EB2.2070805@danbri.org>
	<18783.35370.202167.366672@opera.com>
Message-ID: <495F8E3B.5090504@danbri.org>

On 3/1/09 16:54, H?kon Wium Lie wrote:
> Also sprach Dan Brickley:
>
>   >  My main problem with the natural language processing option is that it
>   >  feels too close to waiting for Artificial Intelligence. I'd rather add 6
>   >  attributes to HTML and get on with life.
>
> :-)

Another thought re NLP. RDFa (and similar, ...) are formats that can be 
used for writing down the conclusions of NLP analysis. For example here 
see the BBC's recent Muddy Boots experiment, using DBPedia (Wikipedia in 
RDF) data to drive autoclassification / named entity recognition. So 
here we can agree with Ian and others that text analysis has much to 
offer, and still use RDFa (or other semantic markup - i'll sidestep that 
debate for now) as a notation for marking up the words with a 
machine-friendly indicator of their NLP-guessed meaning.

http://www.bbc.co.uk/blogs/journalismlabs/2008/12/muddy_boots.html

> Personally, I think the 'class' attribute may still be a more
> compelling option in a less-is-more way. It already exists and can
> easily be used for styling purposes. Styling is bait for authors to
> disclose semantics.

I'm sure there's mileage to be had there. I'm somehow incapable of 
writing XSLT so GRDDL hasn't really charmed me, but 'class' certainly 
corresponds to a lot of meaningful markup. Naturally enough it is 
stronger at tagging bits of information with a category than at defining 
relationships amongst the things defined when they're scattered around 
the page. But that's no reason to dismiss it entirely.

Did you see the RDF-EASE draft, 
http://buzzword.org.uk/2008/rdf-ease/spec? From which comes: "Ten second 
sales pitch: CSS is an external file that specifies how your document 
should look; RDF-EASE is an external file that specifies what your 
document means."

RDF-EASE uses CSS-based syntax. More discussion here, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0148.html 
including question of whether it ought to be expressed using 
css3-namespace, 
http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0175.html

chers,

Dan

--
http://danbri.org/



From scampa.giovanni at gmail.com  Sat Jan  3 08:37:16 2009
From: scampa.giovanni at gmail.com (Giovanni Campagna)
Date: Sat, 3 Jan 2009 17:37:16 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F8E3B.5090504@danbri.org>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
	<495E552B.5070004@gmx.de>
	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de> <495F7EB2.2070805@danbri.org>
	<18783.35370.202167.366672@opera.com> <495F8E3B.5090504@danbri.org>
Message-ID: <65307430901030837v69ed199sbca6a7e171dd143d@mail.gmail.com>

I've tried to follow all the discussion besides of its lengths and my
conclusion is:
You're asking the wrong question

People against RDFa in HTML5 are asking "why do you need RDFa?", and
supporters of the proposal are actually describing the benefits of RDFa
itself.

The right question is: why do you need RDFa *inside HTML5*?

My personal answer to this question is:
There is no needing for RDFa inside HTML5. There are other markup languages
which support RDFa natively (XHTML for example).
You may say that in this way you help to divide the web in two sides, users
of HTML5 and users of XHTML2.

Actually the web, is already divided in two big groups:
- Web of data
- Web of interaction

Web of data means all the page whose primary objective is to provide some
information, either user-readable or machine-readable to the users, while
web of interaction include web application, whose primary purpose is to
provide additional services to the users.
These two groups have very different requirements (GMail doesn't need RDFa
in application code, while Wikipedia doesn't need a progress element), so
specific markup languages may suit better the web site.
Moreover, this distinction is not a requirement, is just an advice: you can
put metadata inside HTML5 using Microformats and you can put interactivity
inside XHTML2 using XMLEvents.

Summing up: if you author feel the absolute needing for metadata, because
delivering content to the users is your primary goal, then switch from HTML5
to something else, and leave HTML5 to web application, focused on user
interaction.

Giovanni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090103/cc05eaf3/attachment.htm>

From alex.baldacchino at email.it  Sat Jan  3 08:51:53 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sat, 03 Jan 2009 17:51:53 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um19y5ajwxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
Message-ID: <495F97A9.1080602@email.it>

Charles McCathieNevile ha scritto:
>>> The results of the first set of Microformats efforts were some pretty
>>> cool applications, like the following one demonstrating how a web
>>> browser could forward event information from your PC web browser to 
>>> your
>>> phone via Bluetooth:
>>>
>>> http://www.youtube.com/watch?v=azoNnLoJi-4
>>
>> It's a technically very interesting application. What has the adoption
>> rate been like? How does it compare to other solutions to the problem,
>> like CalDav, iCal, or Microsoft Exchange? Do people publish calendar
>> events much? There are a lot of Web-based calendar systems, like 
>> MobileMe
>> or WebCalendar. Do people expose data on their Web page that can be used
>> to import calendar data to these systems?
>
> In some cases this data is indeed exposed to Webpages. However, 
> anecdotal evidence (which unfortunately is all that is available when 
> trying to study the enormous collections of data in private intranets) 
> suggests that this is significantly more valuable when it can be done 
> within a restricted access website.
>
> ...
>>> In short, RDFa addresses the problem of a lack of a standardized
>>> semantics expression mechanism in HTML family languages.
>>
>> A standardized semantics expression mechanism is a solution. The lack 
>> of a solution isn't a problem description. What's the problem that a
>> standardized semantics expression mechanism solves?
>
> There are many many small problems involving encoding arbitrary data 
> in pages - apparently at least enough to convince you that the data-* 
> attributes are worth incorporating.
>
> There are many cases where being able to extract that data with a 
> simple toolkit from someone else's content, or using someone else's 
> toolkit without having to tell them about your data model, solves a 
> local problem. The data-* attributes, because they do not represent a 
> formal model that can be manipulated, are insufficient to enable 
> sharing of tools which can extract arbitrary modelled data.
>

That's because the data-* attributes are meant to create custom models 
for custom use cases not (necessarily) involving interchange and (let me 
say) "agnostic extraction" of data. However, data-* attributes might be 
used to "emulate" support for RDFa attributes, so that each one might be 
mapped to, let's say, a "data-rdfa-<attribute>" one and viceversa (I 
don't think "data-rdfa-about" vs "about" would make a great difference, 
at least in a test phase, since it wouldn't be much different from 
"rdfa:about", which might be used to embed RDFa attributes in a somewhat 
xml language (e.g. an "external" markup embedded in a xhtml document 
through the extension mechanism)).

Since it seems there are several problems which may be addressed (beside 
other, more custom models) by RDFa for organization-wide internal use 
and intranet publication, without the explicit requirement of external 
interchange, when both HTML5 specific features and RDFa attributes are 
felt as necessary, it shouldn't be too difficoult to create a custom 
parser, comforming to RDFa spec and availing of data-* attributes, to be 
plugged in a certain browser supporting html5 (and data-*) for internal 
test first, then exposed to the community, so that html5+rdfa can be 
tested on a wider scale (especially once alike parsers are provided for 
all main browsers), looking for a widespread adoption to point out an 
effective need to merge RDFa into HTML5 spec (or to standardize an 
approach based on data-* attributes).

That is, since RDFa can be "emulated" somehow in HTML5 and tested 
without changing current specification, perhaps there isn't a strong 
need for an early adoption of the former, and instead an "emulated" 
mergence might be tested first within current timeline.

>> What is the cost of having different data use specialised formats?
>
> If the data model, or a part of it, is not explicit as in RDF but is 
> implicit in code made to treat it (as is the case with using scripts 
> to process things stored in arbitrarily named data-* attributes, and 
> is also the case in using undocumented or semi-documented XML formats, 
> it requires people to understand the code as well as the data model in 
> order to use the data. In a corporate situation where hundreds or tens 
> of thousands of people are required to work with the same data, this 
> makes the data model very fragile.
>

I'm not sure RDF(a) solves such a problem. AIUI, RDFa just binds (xml) 
properties and attributes (in the form of curies) to RDF concepts, 
modelling a certain kind of relationships, whereas it relies on external 
schemata to define such properties. Any undocumented or semi-documented 
XML formats may lead to misuses and, thus, to unreliably modelled data, 
and it is not clear to me how just creating an explicit relationship 
between properties is enough to ensure that a property really represents 
a subject and not a predicate or an object (in its wrongly documented 
schema), if the problem is the correct definition of the properties 
themselves. Perhaps it is enough to parse them, and perhaps it can 
"inspire" a better definition of the external schemata (if the RDFa 
"vision" of data as triples is suitable for the effective data to 
model), but if the problem is the right understanding of "what 
represents what" because of a lack in documentations, I think that's 
something RDF/RDFa can't solve.

I think the same applies to data-* attributes, because _they_ describe 
data (and data semantics) in a custom model and thus _they_ need to be 
documented for others to be able to manipulate them; the use of a custom 
script rather than a built-in parser does not change much from this 
point of view.


> [not clear what the context was here, so citing as it was]
>>> > I don't think more metadata is going to improve search engines. In
>>> > practice, metadata is so highly gamed that it cannot be relied upon.
>>> > In fact, search engines probably already "understand" pages with far
>>> > more accuracy than most authors will ever be able to express.
>>>
>>> You are correct, more erroneous metadata is not going to improve search
>>> engines. More /accurate/ metadata, however, IS going to improve search
>>> engines. Nobody is going to argue that the system could not be gamed. I
>>> can guarantee that it will be gamed.
>>>
>>> However, that's the reality that we have to live with when introducing
>>> any new web-based technology. It will be mis-used, abused and 
>>> corrupted.
>>> The question is, will it do more good than harm? In the case of RDFa
>>> /and/ Microformats, we do think it will do more good than harm.
>>
>> For search engines, I am not convinced. Google's experience is that
>> natural language processing of the actual information seen by the actual
>> end user is far, far more reliable than any source of metadata. Thus 
>> from
>> Google's perspective, investing in RDFa seems like a poorer investment
>> than investing in natural language processing.
>
> Indeed. But Google is something of an edge case, since they can afford 
> to run a huge organisation with massive computer power and many 
> engineers to address a problem where a "near-enough" solution brings 
> themn the users who are in turn the product they sell to advertisers. 
> There are many other use cases where a small group of people want a 
> way to reliably search trusted data.
>

I think the point with general purpose search engines is another one: 
natural language processing, whereas being expensive, grants a far more 
accurate solution than RDFa and/or any other kind of metadata can bring 
to a problem requiring data must never need to be trusted (and, instead, 
a data processor must be able to determine data's level of trust without 
any external aid). Since there is no "direct" relationship between the 
semantics expressed by RDFa and the real semantics of a web page 
content, relying on RDFa metadata would lead to widespread cheats, as it 
was when the keywords meta tag was introduced. Thus, a trust 
chain/evaluation mechanism (such as the use of signatures) would be 
needed, and so a general purpose search engine relying on RDFa would 
seem to be working more as a search directory, where human beings 
analyse content to classify pages, resulting in a more accurate result, 
but also in a smaller and very slowly growing database of classified 
sites (since obviously there will always be far more sites not caring of 
metadata and/or of making their metadata trusted, than sites using 
trusted RDFa metadata).

(the same reasoning may apply to a local search made by a browser in its 
local history: results are reliable as far as the expressed semantics is 
reliable, that is as far as its source is reasonably trusted, which may 
not be true in general - in general, misuses and deliberate abuses 
whould be the most common case without a trust evaluation mechanism, 
which, in turn, would restrict the number of pages where the presence of 
rdf(a) metadata is really helpful).

My concern is that any data model requiring any level of trust to 
achieve a good-working interoperability may address very small (and 
niche) use cases, and even if a lot of such niche use cases might be 
grouped in a whole category consistently addressed by RDFa (perhaps 
beside other models), the result might not be an enough significant use 
case fitting actual specification guidelines (which are somehow hostile 
to (xml) extensibility, as far as I've understood them) -- though they 
might be changed when and if really needed.

Best regards,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Meetic trovi milioni di single, iscriviti adesso e inizia subito a fare nuove amicizie
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8290&d=3-1


From alex.baldacchino at email.it  Sat Jan  3 11:22:25 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sat, 03 Jan 2009 20:22:25 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F7EB2.2070805@danbri.org>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>	<495E552B.5070004@gmx.de>	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>	<495F61FA.50405@gmx.de>
	<495F7EB2.2070805@danbri.org>
Message-ID: <495FBAF1.2090502@email.it>

Dan Brickley ha scritto:
> On 3/1/09 14:02, Julian Reschke wrote:
>> Tab Atkins Jr. wrote:
>>> The most successful alternative is nothing at all. ^_^ We can
>>> extract copious data from web pages reliably without metadata, either
>>> using our human senses (in personal use) or natural-language-based
>>> processing (in search engine use). It has not yet been established
>>> that sufficient and significant enough problems *exist* to justify a
>>> solution, let alone one that requires an addition to html. That is
>>> what Ian is specifically looking for.
>>
>> That's what you and Ian claim. Many disagree.
>
> My main problem with the natural language processing option is that it 
> feels too close to waiting for Artificial Intelligence. I'd rather add 
> 6 attributes to HTML and get on with life.
>
> But perhaps a more practical concern is that it unfairly biases things 
> towards popular languages - lucky English, lucky Spanish, etc., and 
> those that lend themselves more to NLP analysis. *The Web is for 
> everyone*, and people shouldn't be forced to read and write English to 
> enjoy the latest advances in *Web automation*. Since HTML5 is going 
> through W3C, such considerations need to be taken pretty seriously.
>

My concern is: is RDFa really suitable for everyone and for Web 
automation? My own answer, at first glance, is no. That's because RDF(a) 
can perhaps address nicely very niche needs, where determining how much 
data can be trusted is not a problem, but in general misuses AND 
deliberate abuses may harm automation heavily, since an automaton is 
unlikely to be able to understand whether metadata express the real 
meaning of a web page or not (without a certain degree of AI).

If an external mechanism is needed to determine trust level for 
metadata, that is to establish when an automation results are good or 
bad, such a mechanism may involve human beings at some stage, thus 
breaking automation (this is somehow similar to the problem of defining 
an "oracle machine" described by Turing, according to whom such a 
machine isn't an automaton).

On another hand, a very custom model thought for very custom needs (and 
not requiring wide support) may be less prone to abuses, since it's 
unlikely to find someone willing to cheat himself. Thus, having third 
parties agreeing a certain model and related APIs, and implementing APIs 
on their own sides, might be more reliable in some cases (anyway, third 
parties should agree their respective metadata are reliable and find a 
way to evaluate they really are).

Dan Brickley ha scritto:
> On 3/1/09 16:54, H?kon Wium Lie wrote:
>> Also sprach Dan Brickley:
>>
>>   >  My main problem with the natural language processing option is 
>> that it
>>   >  feels too close to waiting for Artificial Intelligence. I'd 
>> rather add 6
>>   >  attributes to HTML and get on with life.
>>
>> :-)
>
> Another thought re NLP. RDFa (and similar, ...) are formats that can 
> be used for writing down the conclusions of NLP analysis. For example 
> here see the BBC's recent Muddy Boots experiment, using DBPedia 
> (Wikipedia in RDF) data to drive autoclassification / named entity 
> recognition. So here we can agree with Ian and others that text 
> analysis has much to offer, and still use RDFa (or other semantic 
> markup - i'll sidestep that debate for now) as a notation for marking 
> up the words with a machine-friendly indicator of their NLP-guessed 
> meaning.
>
> http://www.bbc.co.uk/blogs/journalismlabs/2008/12/muddy_boots.html
>
>> Personally, I think the 'class' attribute may still be a more
>> compelling option in a less-is-more way. It already exists and can
>> easily be used for styling purposes. Styling is bait for authors to
>> disclose semantics.
>
> I'm sure there's mileage to be had there. I'm somehow incapable of 
> writing XSLT so GRDDL hasn't really charmed me, but 'class' certainly 
> corresponds to a lot of meaningful markup. Naturally enough it is 
> stronger at tagging bits of information with a category than at 
> defining relationships amongst the things defined when they're 
> scattered around the page. But that's no reason to dismiss it entirely.
>
> Did you see the RDF-EASE draft, 
> http://buzzword.org.uk/2008/rdf-ease/spec? From which comes: "Ten 
> second sales pitch: CSS is an external file that specifies how your 
> document should look; *RDF-EASE is an external file that specifies 
> what your document means.*"
>
> RDF-EASE uses CSS-based syntax. More discussion here, 
> http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0148.html 
> including question of whether it ought to be expressed using 
> css3-namespace, 
> http://lists.w3.org/Archives/Public/semantic-web/2008Dec/0175.html
>
> chers,
>
> Dan
>
> -- 
> http://danbri.org/
>

My question is: how often can I trust such a file specifies what your 
document really means, without evaluating its content?

I'd distinguish two cases (not pretendig to make a complete classification),

- The semantics described by metadata is used for server-side 
computations: there's no need to evaluate content (since I'm trusting to 
you when navigating your site, and it's unlikely to find you purposedly 
messing with yourself), as well as to have client-side support for such 
metadata (by the UA). This is the case of a centralised database.

For instance, a *pedia page may send queries to the server, which 
elaborates them and sends results back the the user.

- The UA must understand metadata and automatically gather informations 
meshed-up in a page from several sources: each source must be actively 
evaluated and trusted (a bot can't do such). This is the case of a 
decentralized database.

For instance, that's easy to think of a spamming advertiser who 
apparently puts honest content into your pages (which maybe take 
reliable content from dbpedia), whereas he uses fake metadata to cheat 
my browser and send me irrelevant informations (or infos I'm not 
interested in) when I ask for related content [1], perhaps without you 
even guessing what's going on (and you may be loosing visitors because 
of that).

For obvious reasons, a trust evaluation mechanism can't be as easy as 
getting/creating a signature to be used in a secure connection, because 
someone must actively evaluate at least two things:
- the metadata really reflects a resource content, and
- the metadata is properly used with respect to an external schema 
involved to model data (otherwise, no relationship would be reliable -- 
however, such might be a minor concern from a certain angle, since 
misused metadata might be less harmful than deliberately abused ones).

The result can be very expensive (as certifying a driver or an 
application for a certain platform), or lead to a free choice to avoid 
any evaluation and instead to trust to any third parties. Both solutions 
may work, perhaps, for niche/limited cases, but I don't think such may 
be a good base for a "global" - and general purpose - automation.

[1] That's not the same as using the @rel attribute without any 
relationship with other metadata: a UA may just provide a link somehow 
described as pointing to a related resource with respect to the 
surrounding content, so that I can choose to follow such a link or not; 
if the @rel attribute is used by an automated mechanism in response to a 
query and with respect to other metadata, the UA must decide on its own 
if a link is worth to be followed or not, and I don't think there is any 
easy way to take automated decisions involving trust.

Best regards,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Incrementa la visibilita' della tua azienda con l'invio di newsletter e campagne email marketing.
* Con investimento di soli 250 Euro puoi incrementare la tua visibilita'
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8350&d=3-1


From mail at tobyinkster.co.uk  Sat Jan  3 16:13:23 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sun, 4 Jan 2009 00:13:23 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
Message-ID: <18BAFD7F-43A5-48E4-A871-9542944D49EB@tobyinkster.co.uk>

Calogero Alex Baldacchino wrote:

> My concern is: is RDFa really suitable for everyone and for Web
> automation? My own answer, at first glance, is no. That's because  
> RDF(a)
> can perhaps address nicely very niche needs, where determining how  
> much
> data can be trusted is not a problem, but in general misuses AND
> deliberate abuses may harm automation heavily

If your agent isn't going to trust the data gleaned from RDFa, then  
why should it trust the data gleaned from the web page's natural  
language? If the page has been authored by a reprobate that cannot be  
trusted to put honest and correct data in a few RDFa attributes, why  
should we trust their prose text?

An oft-quoted answer is that the prose text is "visible" whereas the  
RDFa is somehow "invisible". Apart from the fact that UIs which make  
use of data pulled in from RDFa will make this data visible, there is  
also the fact that RDFa, unlike an external RDF/XML file, or some  
metadata embedded in a <script> block, makes use of as much visible  
data as possible: visible links, visible text, etc.

	<p>My name is <span property="foaf:name"
	  about="#me">Toby Inkster</span>.</p>

If you can't trust someone to correctly mark up what their name is,  
then why trust them to mark up what deserves <em>phasis? Why believe  
the <address> they provide? What if the instance they marked up with  
<dfn> is not really the defining one? What if a <var> is really a  
constant?

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




From chaals at opera.com  Sat Jan  3 17:14:49 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Sun, 04 Jan 2009 12:14:49 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<495D0EB9.3090407@takkaria.org> <op.um38vt1gwxe0ny@widsithpro.lan>
	<dd0fbad0901020952l1241d59dlf23676808b35b304@mail.gmail.com>
Message-ID: <op.um7kezvnwxe0ny@widsithpro.lan>

On Sat, 03 Jan 2009 04:52:35 +1100, Tab Atkins Jr. <jackalmage at gmail.com>  
wrote:

> On Fri, Jan 2, 2009 at 12:12 AM, Charles McCathieNevile
> <chaals at opera.com> wrote:
>> On Fri, 02 Jan 2009 05:43:05 +1100, Andi Sidwell <andi at takkaria.org>  
>> wrote:
>>
>>> On 2009-01-01 15:24, Toby A Inkster wrote:
>>>>
>>>> The use cases for RDFa are pretty much the same as those for
>>>> Microformats.
>>>
>>> Right, but microformats can be used without any changes to the HTML
>>> language, whereas RDFa requires such changes.  If they fulfill the  
>>> same use
>>> cases, then there's not much point in adding RDFa.
>>
>> ...
>
> Why the non-response?

Because the response comes in the next paragraph, to the first question  
that was worth asking.

>>>> So why RDFa and not Microformats?
>>
>> (I think the question should be why RDFa is needed *as well as*  
>> ?formats)
>
> This is correct.  Microformats exist already.  They solve current
> problems.

(Elsewhere in this thread you wrote
[[[
It has not yet been established that there is a problem worth solving that  
metadata would address at all.
]]]
Do you consider that ?formats do not encode metadata? Otherwise, I am not  
sure how to reconcile these statements. In any case I would greatly  
appreciate clarification of what you think microformats do, since I do  
believe that microformats are very explicitly directed to allowing the  
encoding of metadata, anbd therefore it is not clear that we are  
discussing from similar premises).

>  Are there further problems that Microformats don't address
> which can be solved well by RDFa?  Are these problems significant
> enough to authors to be worth addressing in the spec, or can we wait
> and let the community work out its own solutions further before we
> make a move?

In my opinion, yes there are further problems ?formats don't solve (that  
RDFa does), yes they are significant, and the community has come up with a  
way to solve them - RDFa.

> Microformats are the metadata equivalent of Flash-based video players.
>  They are hacks used to allow authors to accomplish something not
> explicitly accounted for in the language.  Are there significant
> problems with this approach?

Yes. The problems are that they rely on precoordination on a  
per-vocabulary basis before you can do anything useful with the data. In  
practical usage they rely on choosing attribute names that hopefully don't  
clash with anything - in other words, trying to solve the problem of  
disambiguation that namespaces solves, but by choosing names that are  
wierd enough not to clash or by circumscribing the problem spaces that can  
be addressed to the extent that you can expect no clashes.

(This is hardly news, by the way).

> Is metadata embedding used widely enough
> to justify extending the language for it, or are the current hacks
> (Microformats, in this case) enough?  Are current metadata embedding
> practices mature enough that we can be relatively sure we're solving
> actual problems with our extension?

Current metadata embedding is done using ?formats, and it's pretty clear  
that they are not sufficient. A large body of work uses RDF data models  
(Dublin Core, IMS, LOM, FOAF, POWDER are all large-scale formats. The  
people who are testing RDF engines with hundreds of millions of triples  
and more are doing it with real data, not stuff generated for the  
experiment).

It is also clear that people would like to develop further small-scale  
formats, and that ?formats through its requirement for community  
consultation is effectively too heavyweight for the purposes of many  
developers.

>  These are all questions that must
> be asked of any extention to the language.
>
>>>> Firstly, RDFa provides a single unified parsing algorithm that
>>>> Microformats do not. ...
>>
>>> This is not necessarily beneficial.  If you have separate parsing
>>> algorithms, you can code in shortcuts for common use-cases and thus  
>>> optimise the authoring experience.
>>
>> On the other hand, you cannot parse information until you know how it is
>> encoded, and information encoded in RDFa can be parsed without knowing  
>> more.
>>
>> And not only can you optimise your parsing for a given algorithm, you  
>> can also do for a known vocabulary - or you can optimise the
>> post-parsing treatment.
>
> What is the benefit to authors of having an easily machine-parsed
> format?

Assuming that the format is sufficiently easy to write, and to generate, I  
am not sure what isn't obvious about the answer to the question.

(In case I am somehow very clever, and others aren't, the benefit is that  
it is easy to machine parse and use the information).

> Are they greater than the benefits of a
> format that is harder to parse, but easier for authors to write?

For a certain set of authors, yes the benefits are greater.

>>>  Also, as has been pointed out before in the distributed extensibility
>>> debate, parsing is a very small part of doing useful things with  
>>> content.
>>
>> Yes. However many of the use cases that I think justify the inclusion of
>> RDFa are already very small on their own, and valuable when several
>> vocabularies are combined. So being able to do off-the-shelf parsing is
>> valuable, compared to working out how to parse a combination of formats
>> together.
>
> Can you provide these use-cases?  The discussion has an astonishing
> dearth of use-cases by which we can evaluate the effectiveness of
> proposals.

The small-scale use cases are difficult to provide, since they are based  
on the fact that people do something quickly because they need it. One set  
of potential use cases is all the microformats that haven't been blessed  
by the ?formats community as formally agreed "standards" - writing them in  
RDFa is sufficient to have them be usable.

Another use case is noting the source of data in mashups. This enables  
information to be carried about the licensing, the date at which the data  
was mashed (or smushed, to use the older terminology from the Semantic  
Web), and so on.

Another (the second time I have noted it in two emails) is to provide  
information useful for improving the accessibility of Web content.

The set of use cases that led to the development of GRDDL are also use  
cases for RDFa - since RDFGa allows a direct extraction to RDF without  
having to develop a new parser for each data model, authors can simplify  
the way they extract data by using RDFa to encode it, saving themselves  
the bother of explaining how to extract it. This time saving means that  
they can afford to develop a smaller, more specialised vocabulary.

> Is there any indication that use of
> ambiguous names produces significant problems for authors?

Not that I am aware of, although I think the question is poorly considered  
so I haven't given it much thought. There is plenty of evidence (for  
example the attempts to use Dublin Core within existing HTML mechanisms)  
that it causes problems for data consumers.

>>>> It can be argued that going through a
>>>> community to develop vocabularies is beneficial, as it allows the
>>>> vocabulary to be built by "many minds" - RDFa does not prevent this,  
>>>> it
>>>> just gives people alternatives to community development.
>>>
>>> RDFa does not give anything over what the class attribute does in  
>>> terms of
>>> community vs individual development, so this doesn't really speak in  
>>> RDFa's
>>> favour.
>>
>> In principle no, but in real world usage the class attribute is  
>> considered something that is primarily local, whereas RDFa is generally
>> used by people who have a broader outlook on the desirable permanence
>> and re-usability of their data.
>
> Can we extract a requirement from this, then?

A poor formulation (I hope that those who are better at very detailed  
requirements can help improve my phrasing) could be:

Provide an easy mechanism to encode new data in a way that can be  
machine-extracted without requiring any explanation of the data model.

>>>> Lastly, there are a lot of parsing ambiguities for many Microformats.
>>>> One area which is especially fraught is that of scoping. The editors  
>>>> of
>>>> many current draft Microformats[1] would like to allow page authors to
>>>> embed licensing data - e.g. to say that a particular recipe for a pie  
>>>> is
>>>> licensed under a Creative Commons licence. However, it has been noted
>>>> that the current rel=license Microformat can not be re-used within  
>>>> these
>>>> drafts, because virtually all existing rel=license implementations  
>>>> will
>>>> just assume that the license applies to the whole page rather than  
>>>> just
>>>> part of it. RDFa has strong and unambiguous rules for scoping - a
>>>> license, for example, could apply to a section of the page, or one
>>>> particular image.
>>>
>>> Are there other cases where this granularity of scoping would be  
>>> genuinely
>>> helpful?  If not, it would seem better to work out a solution for  
>>> scoping
>>> licence information...
>>
>> Yes.
>>
>> Being able to describe accessibility of various parts of content, or  
>> point
>> to potential replacement content for particular use cases, benefits
>> enormously from such scoping (this is why people who do industrial-scale
>> accessibility often use RDF as their infrastructure). ARIA has already  
>> taken
>> the approach of looking for a special-purpose way to do this, which
>> significantly bloats HTML but at least allows important users to satisfy
>> their needs to be able t produce content with certain information  
>> included.
>>
>> Government and large enterprises produce content that needs to be
>> maintained, and being able to include production, cataloguing, and  
>> similar
>> metadata directly, scoped to the document, would be helpful. As a  
>> trivial
>> example, it would be useful to me in working to improve the Web content  
>> we
>> produce at Opera to have a nice mechanism for identifying the original
>> source of various parts of a page.
>
> Can we distill this into use-cases, then?

Sure. It just takes a small amount of thinking. How many use cases would  
you think will be sufficient to demonstrate that this would be important.  
Or do you measure it by how many people each use case applies to? (It is  
far easier to justify the cost of developing use cases where there is more  
clarity about the goals for those use cases - and it enables people to  
decide whether to develop their own, or go find the people who are doing  
this and ask them to provide the information).

>  You, as an author, want to
> be able to specify the original source of a piece of content.  What's
> the practical use of this?  Does it require an embedded,
> machine-readable vocabulary to function?  Are existing solutions
> adequate (frex, footnotes)?
...
> Not quite.  Specifically, is there any practical use for marking up
> various sections of a site with licensing information specific to that
> section *in an embedded, machine-readable manner*?  Are the existing
> solutions adequate (frex, simply putting a separate copyright notice
> on each section, or noting the various copyrights on a licensing
> page)?

Let me treat these as the same question since I don't think they introduce  
anything usefully different between them. I will add to that Henri's  
questions about my use case for this already published elsewhere in this  
thread.

A practical use case is in an organisation where different people are  
responsible for different parts of content. Instead of having to look up,  
myself, who is responsible for each piece, and what rights are associated  
with it, I can automate the process. (This is one of the value  
propositions offered by content management systems. I hope we can agree  
that these are sufficiently widely used to a priori assume a use case, but  
if not please say so). This means that instead of manually checking many  
pages for things like accessibility or being up to date, and then having  
to find which part of the page was produced by which part of the  
organisation (which is what I do at Opera) I can simply have this  
information trawled and presented as I please by a program (which many  
large organisations do, or partially do).

Another example is that certain W3C pages (the list of specifications  
produced by W3C, for example, and various lists of translations) are  
produced from RDF data that is scraped from each page through a customised  
and thus fragile scraping mechanism. Being able to use RDFa would free  
authors of the draconian constraints on the source-code formatting of  
specifications, and merely require them to us the right attributes, in  
order to maintain this data.

An example of how this data can be re-used is that it is possible to  
determine many of the people who have translated W3C specifications or  
other documents - and thus to search for people who are familiar with a  
given technology at least at some level, and happen to speak one or more  
languages of interest. This is at least as important to me in looking for  
potential people to recruit as any free-text search I can do - and has the  
benefit that while I don't have the resources to develop large-scale  
free-text searching, I do have the resources to develop simple queries  
based on a standardised data model and an encoding of it.

Alternatively I could use the same information to seed a reputation  
manager, so I can determine which of the many emails I have no time to  
read in WHAT-WG might be more than usually valuable.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From chaals at opera.com  Sat Jan  3 17:49:09 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Sun, 04 Jan 2009 12:49:09 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F97A9.1080602@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
Message-ID: <op.um7lz7ufwxe0ny@widsithpro.lan>

On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino  
<alex.baldacchino at email.it> wrote:

> Charles McCathieNevile ha scritto:
> ... it shouldn't be too difficoult to create a custom parser, comforming  
> to RDFa spec and availing of data-* attributes...
>
> That is, since RDFa can be "emulated" somehow in HTML5 and tested  
> without changing current specification, perhaps there isn't a strong  
> need for an early adoption of the former, and instead an "emulated"  
> mergence might be tested first within current timeline.

In principle this is possible. But the data-* attributes are designed for  
private usage, and introducing a public usage means creating a risk of  
clashes that pollute RDFa data gathered this way. In other words, this is  
indeed feasible, but one would expect it to show that the data generated  
was unreliable (unless privately nobody is interested in basic terms like  
about). Such results have been used to suggest that poorly implemented  
features should be dropped, but this hypothetical case suggests to me that  
the argument is wrong, and that if in the face of reasons why the data  
would be bad people use them, one might expect better usage by formalising  
the status of such features and getting decent implementations.

>>> What is the cost of having different data use specialised formats?
>>
>> If the data model, or a part of it, is not explicit as in RDF but is  
>> implicit in code made to treat it (as is the case with using scripts to  
>> process things stored in arbitrarily named data-* attributes, and is  
>> also the case in using undocumented or semi-documented XML formats, it  
>> requires people to understand the code as well as the data model in  
>> order to use the data. In a corporate situation where hundreds or tens  
>> of thousands of people are required to work with the same data, this  
>> makes the data model very fragile.
>>
>
> I'm not sure RDF(a) solves such a problem. AIUI, RDFa just binds (xml)  
> properties and attributes (in the form of curies) to RDF concepts,  
> modelling a certain kind of relationships, whereas it relies on external  
> schemata to define such properties. Any undocumented or semi-documented  
> XML formats may lead to misuses and, thus, to unreliably modelled data,
...

> I think the same applies to data-* attributes, because _they_ describe  
> data (and data semantics) in a custom model and thus _they_ need to be  
> documented for others to be able to manipulate them; the use of a custom  
> script rather than a built-in parser does not change much from this  
> point of view.

RDFa binds data to RDF. RDF provides a well-known schema language with  
machine-processable definition of vocabularies, and how to merge  
information between them. In other words, if you get the underlying model  
for your data right enough, people will be able to use it without needing  
to know what you do.

Naturally not everyone will get their data model right, and naturally not  
all information will be reliable anyway. However, it would seem to me that  
making it harder to merge the data in the first place does not assist in  
determining whether it is useful. On the other hand, certain forms of RDF  
data such as POWDER, FOAF, Dublin Core and the like have been very  
carefully modelled, and are relatively well-known and re-used in other  
data models. Making it easy to parse this data and merge it, according to  
the existing well-developed models seems valuable.


>> Ian wrote:
>>> For search engines, I am not convinced. Google's experience is that
>>> natural language processing of the actual information seen by the  
>>> actual end user is far, far more reliable than any source of metadata.
>>> Thus from Google's perspective, investing in RDFa seems like a poorer
>>> investment than investing in natural language processing.
>>
>> Indeed. But Google is something of an edge case, since they can afford  
>> to run a huge organisation with massive computer power and many  
>> engineers to address a problem where a "near-enough" solution brings  
>> themn the users who are in turn the product they sell to advertisers.  
>> There are many other use cases where a small group of people want a way  
>> to reliably search trusted data.
>>
>
> I think the point with general purpose search engines is another one:  
> natural language processing, whereas being expensive, grants a far more  
> accurate solution than RDFa and/or any other kind of metadata can bring  
> to a problem requiring data must never need to be trusted (and, instead,  
> a data processor must be able to determine data's level of trust without  
> any external aid).

No, I don't think so. Google searches based on analysis of the open web  
are *not* generally more reliable than faceted searches over a reliable  
dataset, and in some instances are less reliable.

The point is that only a few people can afford to invest in being a  
general-purpose search engine, whereas many can afford to run a  
metadata-based search system over a chosen dataset, that responds to their  
needs (and doesn't require either publishing their data, or paying Google  
to index it).

> Since there is no "direct" relationship between the semantics expressed  
> by RDFa and the real semantics of a web page content, relying on RDFa  
> metadata would lead to widespread cheats, as it was when the keywords  
> meta tag was introduced.

Sure. There would also be many many cases of organisations using decent  
metadata, as with existing approaches. My point was that I don't expect  
Google to naively trust metadata it finds on the open web, and in the  
general case probably not even to look at it. However, Google is not the  
measure of the Web, it is a company that sells advertising based on  
information it has gleaned about users by offering them services.

So the fact that some things on the Web are not directly beneficial to  
Google isn't that important. I do not see how the presence of explicit  
metadata threatens google any more than the presence of plain text (which  
can also be misleading).

> Thus, a trust chain/evaluation mechanism (such as the use of signatures)  
> would be needed,

Indeed such a thing is needed for a general purpose search engine. But  
there are many cases where an alternative is fine. For example, T-mobile  
publish POWDER data about web pages. Opera doesn't need to believe all the  
POWDER data it finds on the Web in order to improve its offerings based on  
T-mobile's data, if we can decide how to read that specific data. Which  
can be done by deciding that we trust a particular set of URIs more than  
others. No signature necessary, beyond the already ubiquitous TLS and the  
idea that we trust people we have a relationship with and whose domains we  
know.

> My concern is that any data model requiring any level of trust to  
> achieve a good-working interoperability may address very small (and  
> niche) use cases, and even if a lot of such niche use cases might be  
> grouped in a whole category consistently addressed by RDFa (perhaps  
> beside other models), the result might not be an enough significant use  
> case fitting actual specification guidelines (which are somehow hostile  
> to (xml) extensibility, as far as I've understood them) -- though they  
> might be changed when and if really needed.

A concern of mine is that it is unclear what the required level of  
usefulness is. The "google highlight" element (once called m but I think  
it changed its name again) is currently in the spec, the longdesc  
attribute currently isn't.  I presume these facts boil down to judgement  
calls by the editor while the spec is still an early draft, but it is not  
easy to understand what information would determine whether something is  
"sufficiently important". Which makes it hard to determine whether it is  
worth the considerable investment of discussing in this group, or easier  
to just go through the W3C process of objecting later on.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From chaals at opera.com  Sat Jan  3 17:49:26 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Sun, 04 Jan 2009 12:49:26 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <18783.35370.202167.366672@opera.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
	<495E552B.5070004@gmx.de>
	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de> <495F7EB2.2070805@danbri.org>
	<18783.35370.202167.366672@opera.com>
Message-ID: <op.um7l0ou2wxe0ny@widsithpro.lan>

On Sun, 04 Jan 2009 02:54:18 +1100, H?kon Wium Lie <howcome at opera.com>
wrote:

> Also sprach Dan Brickley:
>
>  > My main problem with the natural language processing option is that it
>  > feels too close to waiting for Artificial Intelligence. I'd rather  >  
> add 6 attributes to HTML and get on with life.
...
> Personally, I think the 'class' attribute may still be a more
> compelling option in a less-is-more way. It already exists and can
> easily be used for styling purposes. Styling is bait for authors to
> disclose semantics.

I agree that this is a clear first step - and microformats were developed
by paving a cowpath from authors who had done this on their own initiative.

I think the reason for adding the RDFa attributes is that there are cases
where the semantic richness offered by class is insufficient. The relevant
cases are where people are already dealing in rich formalised semantics,
not those where it is a battle to get people to provide any semantics at
all. I think there is a clear benefit in drawing these people to HTML5
rather than suggesting they go off into some different Web.

I used the pattern of adding semantics through class, a decade or so ago,
and in some cases it met my needs perfectly, but in others was
insufficient to enable re-use of the data directly from pages, and forced
me to adopt external systems for managing my data which in turn implied an
increased cost in management because I had to keep the data model clear
although I did not have a simple formalism to specify it at the time.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
       je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From alex.baldacchino at email.it  Sat Jan  3 18:23:57 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 04 Jan 2009 03:23:57 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <18BAFD7F-43A5-48E4-A871-9542944D49EB@tobyinkster.co.uk>
References: <18BAFD7F-43A5-48E4-A871-9542944D49EB@tobyinkster.co.uk>
Message-ID: <49601DBD.3010408@email.it>

Toby A Inkster ha scritto:
> Calogero Alex Baldacchino wrote:
>
>> My concern is: is RDFa really suitable for everyone and for Web
>> automation? My own answer, at first glance, is no. That's because RDF(a)
>> can perhaps address nicely very niche needs, where determining how much
>> data can be trusted is not a problem, but in general misuses AND
>> deliberate abuses may harm automation heavily
>
> If your agent isn't going to trust the data gleaned from RDFa, then 
> why should it trust the data gleaned from the web page's natural 
> language? If the page has been authored by a reprobate that cannot be 
> trusted to put honest and correct data in a few RDFa attributes, why 
> should we trust their prose text?
>

If you sell computers but your site talks about cars I'll never buy a 
notebook from you; thus you're not cheating me, but yourself and 
damaging your business. But if you believe cars are searched more often 
than computers (just an example), one may use false metadata to cheat 
any UAs relying on metadata instead of prose, and take me on a store 
selling computers instead of cars.

Reliability of metadata (with respect to the described data) is an issue 
separated from reliability of content: it's not up to any UA to 
understand AND filter content basing on the author being trusted to be 
saing the truth (such would be a form of censorship), but if I ask the 
UA to bring me a page talking about horses, I don't want it to bring me 
a page talking about v.i.a.g.r.a. (that's spam), thus it is up to any UA 
relying on metadata to understand AND filter them basing on their 
reliability.

> An oft-quoted answer is that the prose text is "visible" whereas the 
> RDFa is somehow "invisible". Apart from the fact that UIs which make 
> use of data pulled in from RDFa will make this data visible, there is 
> also the fact that RDFa, unlike an external RDF/XML file, or some 
> metadata embedded in a <script> block, makes use of as much visible 
> data as possible: visible links, visible text, etc.
>
>     <p>My name is <span property="foaf:name"
>       about="#me">Toby Inkster</span>.</p>
>
> If you can't trust someone to correctly mark up what their name is, 
> then why trust them to mark up what deserves <em>phasis? Why believe 
> the <address> they provide? What if the instance they marked up with 
> <dfn> is not really the defining one? What if a <var> is really a 
> constant?
>

I don't really need a proper markup to understand a name is a name, a 
variable is a variable, a definition is a definition, and so on; you can 
use plain text and I'll understand your content the same way. If one 
makes a mistake when combining a <dfn> with an anchor, the result may be 
a broken link, perhaps making me look for a better site. If one's 
misusing <var> or <em>, the worst possible consequence is a bad 
presentation, and a bad presentation can be an attempt to cheat a UA (as 
when people puts a lot of keywords in a page and style them with the 
same color as the background to cheat search engines), but such is only 
if it is a deliberate choice, not a misuse (and I'm concerning mainly on 
abuses) -- anyway, it is easier to cheat a UA by the mean of false 
metadata than cheating a human person by the mean of wrong markup.

If some markup is like,

<p>We sell <a href="www.cheatingcarseller.com" property="foaf:name" 
content="Toby Inkster">cars</a></p>

in any advertisement, I'll notice it's about cars and I'll choice 
whether to follow it or not, basing on my interest at the moment, but if 
I query "Toby Inkster" to a semantic UA blindly relying on metadata, I 
might get a page of a cars webstore instead of your homepage (for instance).

Furthermore, I started my replies from a Charles McCathieNevile's mail, 
explicitly talking about trusted data and (mainly) small use cases, not 
a wide-scale web automation. If there's no agreement about what kind of 
needs are best addressed by RDFa, maybe I have to agree with people 
saying that technology must grow and become more mature (or, at least, 
better understood) before it is merged into HTML5 specification (and 
2023 is far enough to accomplish such a goal :-) ). And I re-throw my 
suggestion to map RDFa attribute to data-rdfa-* attributes and build 
RDFa processor plugins for most common browsers, to test HTML5 and RDFa 
convergence in a wider scale before having browser natively supporting 
RDFa in HTML5 documents (for the purpose of a test - but not only - I 
don't think "data-rdfa-property" vs "rdfa:property" vs "property" would 
be much of a problem).

I'm not saying RDFa is a bad thing, or it is useless, I just don't think 
any kind of markup can fit perfectly the semantic of "random" content 
for the purposes of a "global", wide-scale and automatic classification 
of content.

Best regards,
Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Incrementa la visibilita' della tua azienda con l'invio di newsletter e campagne email marketing.
* Con investimento di soli 250 Euro puoi incrementare la tua visibilita'
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8350&d=4-1


From timeless at gmail.com  Sat Jan  3 21:37:08 2009
From: timeless at gmail.com (timeless)
Date: Sun, 4 Jan 2009 07:37:08 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um7lz7ufwxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>
Message-ID: <26b395e60901032137y65a03d15j67a0235507f28547@mail.gmail.com>

On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile <chaals at opera.com> wrote:
> No, I don't think so. Google searches based on analysis of the open web are
> *not* generally more reliable than faceted searches over a reliable dataset,
> and in some instances are less reliable.

dunno. i use google to search apple, msdn, and a number of other
technical resources because the actual technical resource search
engines are unusable/useless.

i also use gmail (which i presume shares some intelligence with
google) to manage access to bug databases, because it's faster/smarter
than the actual database search engine..

the same ime generally applies to wikis (the search engines are awful).


From chaals at opera.com  Sun Jan  4 00:56:36 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Sun, 04 Jan 2009 19:56:36 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <26b395e60901032137y65a03d15j67a0235507f28547@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>
	<26b395e60901032137y65a03d15j67a0235507f28547@mail.gmail.com>
Message-ID: <op.um75smdswxe0ny@widsithpro.lan>

On Sun, 04 Jan 2009 16:37:08 +1100, timeless <timeless at gmail.com> wrote:

> On Sun, Jan 4, 2009 at 3:49 AM, Charles McCathieNevile  
> <chaals at opera.com> wrote:
>> No, I don't think so. Google searches based on analysis of the open web  
>> are *not* generally more reliable than faceted searches over a reliable  
>> dataset, and in some instances are less reliable.
>
> dunno. i use google to search apple, msdn, and a number of other
> technical resources because the actual technical resource search
> engines are unusable/useless.

Sure. That's wonderful that Google are so good (or sad that the people who  
make the information you rely on are so useless).

> i also use gmail (which i presume shares some intelligence with
> google) to manage access to bug databases, because it's faster/smarter
> than the actual database search engine..

And I use my Opera's filters to search for certain things because they are  
far more efficient than the full-text search I also use. It depends on the  
use cases.

My point is not that Google is bad. It is that there are all kinds of  
search where it is not the best. One set are those which reliy on faceted  
information and on well-developed metadata. I don't know what searches you  
do, but I know that some databases I search are dreadfully maintained and  
free-text is the only sensible approach, while others are well-designed  
and I can get better results from a tool designed for the job I am trying  
to do.

Anecdotal evidence that demonstrates there is a use case for Google is  
something we probably don't need. I think that we are all convinced that  
Ian's employer is important - not least because it kindly pays Ian for his  
work. I think the question is to establish what cases doesn't Google  
serve. (Well, and the rest of the search engine market, who I believe are  
the majority of searches performed globally even on the public internet).  
And my further question to Ian is what are the criteria for deciding  
whether a case is sufficient.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From ian at hixie.ch  Sun Jan  4 01:57:43 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 4 Jan 2009 09:57:43 +0000 (UTC)
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um75smdswxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>
	<26b395e60901032137y65a03d15j67a0235507f28547@mail.gmail.com>
	<op.um75smdswxe0ny@widsithpro.lan>
Message-ID: <Pine.LNX.4.62.0901040922130.25317@hixie.dreamhostps.com>

On Sun, 4 Jan 2009, Charles McCathieNevile wrote:
>
> And my further question to Ian is what are the criteria for deciding 
> whether a case is sufficient.

The process is described here:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F

Deciding whether we need to address a problem or set of use cases is a 
judgement call. The more people a problem affects, the stronger the case 
for fixing it.

Right now I'm still trying to work out what the problem is; most of the 
discussions seem to be centering around RDF, RDFa, and microformats, which 
are solutions, not problems. It has been asserted that problems exist, and 
that they have characteristics for which RDFa is suitable as a solution, 
but detailed descriptions of the problems themselves have been rather 
lacking. Without a clear description of the problem(s) of relevance, 
discussing solutions is meaningless, for we can't evaluate them.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From hsivonen at iki.fi  Sun Jan  4 05:17:39 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 4 Jan 2009 15:17:39 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495F7EB2.2070805@danbri.org>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>	<495E552B.5070004@gmx.de>	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de> <495F7EB2.2070805@danbri.org>
Message-ID: <3B7AFD76-6ED1-4014-8532-64EE32BD4569@iki.fi>

On Jan 3, 2009, at 17:05, Dan Brickley wrote:

> But perhaps a more practical concern is that it unfairly biases  
> things towards popular languages - lucky English, lucky Spanish,  
> etc., and those that lend themselves more to NLP analysis. The Web  
> is for everyone, and people shouldn't be forced to read and write  
> English to enjoy the latest advances in Web automation.

Some languages are higher in the pecking order than others when  
software development is prioritized, and RDFa cannot level the playing  
field here.

Suppose there's a use case that can be satisfactorily addressed by  
applying NLP heuristics to content for the top-tier languages. Even if  
there were an RDF mechanism for addressing the same use case without  
relying on natural language, software aimed for serving the top-tier  
languages would still do the NLP thing for the use case. Thus, the  
development of the parallel RDF-based solution would be borne by the  
communities using the other languages. If the other languages can't  
get the users of the top-tier languages to use the same technical  
solution, they are still at a disadvantage even if an alternative  
technology stack is theoretically possible, because most software  
development effort goes into what makes sense for the top-tier  
languages without the results being applicable also for the other  
languages.

Instead of bearing the cost of developing a totally alternative  
technology stack for the other languages without benefiting from any  
spillover from the effort done for the top-tier languages, it makes  
more sense to invest the effort into building upon the reusable parts  
already developed for the top-tier languages.

(Quick case study about language-sensitive technology adoption and  
markets: When movable type was developed, a *subset* of the alphabet  
used for German--the native language of printing press suppliers--was  
adopted for Finnish. Today, hundreds of years later, digital font  
availability for Finnish is better than font availability for  
languages of comparable installed base that adopted *extensions* for  
the alphabet used for German or that used a totally different script.  
That is, NIH *still* hasn't caught up with the first-mover advantage  
as far as type goes.)

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From hsivonen at iki.fi  Sun Jan  4 06:21:33 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Sun, 4 Jan 2009 16:21:33 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <495E021E.8010407@googlemail.com>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>
	<495E021E.8010407@googlemail.com>
Message-ID: <C3014DFF-C5FD-40A2-B479-072893BD60D7@iki.fi>

On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:

> On 2/1/09 10:38, Henri Sivonen wrote:
>> More to the point, Microformats not only require per-format  
>> processing
>> but the processing required for each Microformat isn't specified at  
>> all.
>> That's bad.
>
> Some do have processing specified (at least to some degree):
>
> http://microformats.org/wiki/hcard-parsing

That's still not a proper parsing spec. Do all microformat consumers  
with significant market share do it that way?

> For the rest, this seems like something fixable, so I'm not sure how  
> this is more to the point?

HTML parsing is fixable, too, but actually fixing it is something that  
didn't happen until the fixing effort was taken to the spec level.

> * http://microformats.org/wiki/parsing-brainstorming (attempt to  
> actually specify precise parsing rules for all microformats)

This one I hadn't seen before. It's clearly a step into a more spec- 
like direction.

> It could of course be the RDFa curie is worse than the disease.

I suspect that is the case.

>> Is the problem in the case of recipes that the provider of the page
>> navigation around the recipe is unwilling to license the navigation  
>> bits
>> under the same license as the content proper?
>
> I thought Toby's example was that each recipe on the page needed a  
> different licence, rather than a distinction between the main  
> content area and the navigation.

Oh. That can be solved by giving each recipe its own URI & HTML page  
and scraping those pages instead of summary pages that might contain  
multiple recipes.

>> In the case of images, why should a program inferring something about
>> licensing trust assertions made in a different HTTP resource  
>> (possibly
>> even from a different Origin)?
>
> Why should it trust assertions made in the same resource?
>
> For example, presumably you could download an image, change its  
> licencing metadata, and host it at your own Origin? Admittedly,  
> that's a little more work than just hotlinking.

Good point. That's a problem if you are examining a previously unknown  
and untrusted site that might have all its content copied from  
somewhere else. Trusting the origin of the data for it licensing does  
help, though, if you are browsing a site you believe to be reputable  
and clueful and want to automate the license discovery part only.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From chaals at opera.com  Sun Jan  4 16:04:54 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Mon, 05 Jan 2009 11:04:54 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <C3014DFF-C5FD-40A2-B479-072893BD60D7@iki.fi>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>
	<7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>
	<495E021E.8010407@googlemail.com>
	<C3014DFF-C5FD-40A2-B479-072893BD60D7@iki.fi>
Message-ID: <op.um9bugnzwxe0ny@widsithpro.lan>

On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:
>> On 2/1/09 10:38, Henri Sivonen wrote:

>>> Is the problem in the case of recipes that the provider of the page
>>> navigation around the recipe is unwilling to license the navigation  
>>> bits under the same license as the content proper?
>>
>> I thought Toby's example was that each recipe on the page needed a  
>> different licence, rather than a distinction between the main content  
>> area and the navigation.
>
> Oh. That can be solved by giving each recipe its own URI & HTML page and  
> scraping those pages instead of summary pages that might contain  
> multiple recipes.

Sure. In which case the problem becomes "doing mashups where data needs to  
have different metadata associated is impossible", so the requirement is  
"enable mashups to carry different metadata about bits of the content that  
are from different sources.

A use case for this:

There are mapping organisations and data producers and people who take  
photos, and each may place different policies. Being able to keep that  
policy information helps people with further mashups avoiding violating a  
policy.

For example, if GreatMaps.com has a public domain policy on their maps,  
CoolFotos.org has a policy that you can use data other than images for  
non-commercial purposes, and Johan Ichikawa has a photo there of my  
brother's caf?, which he has licensed as "must pay money", then it would  
be reasonable for me to copy the map and put it in a brochure for the  
caf?, but not to copy the data and photo from CoolFotos. On the other  
hand, if I am producing a non-commercial guide to caf?s in Melbourne, I  
can add the map and the location of the cafe photo, but not the photo  
itself.

Another use case:
My wife wants to publish her papers online. She includes an abstract of  
each one in a page, but because they are under different copyright rules,  
she needs to clarify what the rules are. A harvester such as the Open  
Access project can actually collect and index some of them with no  
problem, but may not be allowed to index others. Meanwhile, a human finds  
it more useful to see the abstracts on a page than have to guess from a  
bunch of titles whether to look at each abstract.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From t.broyer at ltgt.net  Sun Jan  4 16:25:13 2009
From: t.broyer at ltgt.net (Thomas Broyer)
Date: Mon, 5 Jan 2009 01:25:13 +0100
Subject: [whatwg] Cookie-based HTTP Authentication
	(draft-broyer-http-cookie-auth-00)
Message-ID: <a9699fd20901041625j68bcdf01h1bc6430f803c73dc@mail.gmail.com>

Hi all,

As I previously said, I spent some holiday time to put my thoughts
about "RFC2617-compliant cookie-based authentication" into an Internet
Draft.
Today is my birthday (and the last day of my holidays) so I thought I
should do something special. I therefore submitted version 00 of my
work ("release early, release often" they said).

As written in the draft, discussion should go to the ietf-http-auth
list (if it happened to not be the appropriate list, please tell me so
I can fix it in the next version).

The Security Considerations section is not yet complete but for this
00 draft I though the overall authentication process was the most
important (have a look at the examples too).

Thanks in advance for your feedback.

(My intent is to publish some kind of "reference implementations" and
"proof of concepts" in various languages later in my mercurial
repository http://broyer.info/hg/http-cookie-auth/ but if you'd like
to contribute now, just send me your code!)


---------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission at ietf.org>
Date: Mon, Jan 5, 2009 at 1:15 AM
Subject: New Version Notification for draft-broyer-http-cookie-auth-00
To: t.broyer at ltgt.net



A new version of I-D, draft-broyer-http-cookie-auth-00.txt has been
successfuly submitted by Thomas Broyer and posted to the IETF
repository.

Filename:        draft-broyer-http-cookie-auth
Revision:        00
Title:           Cookie-based HTTP Authentication
Creation_date:   2009-01-04
WG ID:           Independent Submission
Number_of_pages: 11

Abstract:
This document specifies an HTTP authentication scheme for use when
credentials are validated by an out-of-band mechanism (not defined
here) and later communicated to the server through the use of a
cookie.  Which out-of-band mechanism should be used, and how, is
described by the 401 (Unauthorized) response body.  It is common
practice that this mechanism is an HTML form, sending the user's
credentials with the use of an HTTP POST request to a tier URL which
will set a cookie in response; though this document doesn't preclude
the use of other mechanisms.



The IETF Secretariat.





-- 
Thomas Broyer


From robert at ocallahan.org  Sun Jan  4 20:20:52 2009
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 5 Jan 2009 17:20:52 +1300
Subject: [whatwg] HAVE_ENOUGH_DATA firing the "play" event unconditionally?
Message-ID: <11e306600901042020p14df9ac7wfe3be1eb7236bfe@mail.gmail.com>

The spec says:

If the new ready state is HAVE_ENOUGH_DATA
The user agent must queue a task to fire a simple event called canplay,


Should it only fire "canplay" if the previous ready state was
HAVE_CURRENT_DATA or less? Otherwise, going from HAVE_CURRENT_DATA to
HAVE_FUTURE_DATA to HAVE_ENOUGH_DATA would fire "canplay" twice.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090105/2263d0f3/attachment.htm>

From simonp at opera.com  Sun Jan  4 23:03:30 2009
From: simonp at opera.com (Simon Pieters)
Date: Mon, 05 Jan 2009 08:03:30 +0100
Subject: [whatwg] Methods defined for one document called after that
 document is no longer the one being displayed
In-Reply-To: <89657E62-7785-4335-9CE7-BDB4354B27F7@apple.com>
References: <Pine.LNX.4.62.0808050759070.5140@hixie.dreamhostps.com>
	<89657E62-7785-4335-9CE7-BDB4354B27F7@apple.com>
Message-ID: <op.um9u74byidj3kv@zcorpandell.linkoping.osa>

On Wed, 24 Dec 2008 21:04:33 +0100, Maciej Stachowiak <mjs at apple.com>  
wrote:

> On Aug 5, 2008, at 2:12 AM, Ian Hickson wrote:
>
>>
>> I would like some input from browser vendors.
>>
> [...]


Response from one of our developers:

On Thu, 01 Jan 2009 14:54:18 +0100, <jl at opera.com> wrote:

> I agree with Maciej; it would be unfortunate to adopt the behaviour that  
> Ian suggests.  Sure, it would be easy to define, but it isn't  
> necessarily easy to implement at all in an optimized engine.
>
> The third option, which Maciej claims roughly describes Gecko's and  
> Webkit's implementation, sounds quite a lot like Opera's also.  It's in  
> no way trivial to implement either, but it sounds like it is at least  
> widely adopted.
>
> / Jens

-- 
Simon Pieters
Opera Software


From ian at hixie.ch  Tue Jan  6 03:49:25 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 11:49:25 +0000 (UTC)
Subject: [whatwg] Standard method to get/set caret position
In-Reply-To: <004401c4c8d9$91e4dcd0$0b4aa8c0@gregkilwein>
References: <Pine.LNX.4.44.0408291526390.27480-100000@mail.fbsdata.com>
	<Pine.LNX.4.61.0411121037230.8631@dhalsim.dreamhost.com>
	<004401c4c8d9$91e4dcd0$0b4aa8c0@gregkilwein>
Message-ID: <Pine.LNX.4.62.0901061118580.24109@hixie.dreamhostps.com>

On Fri, 12 Nov 2004, Greg Kilwein wrote:
> > >
> > > The second situation is an application that would like to highlight 
> > > text in a text box or textarea for the purposes of a spell check, 
> > > thesaurus, or search-and-replace operation.
> > 
> > In this case you want more of a highlighting API than a selecting API, 
> > though, right?
> 
> Yes.  If it were possible, highlighting could be accomplished by styling 
> a portion of the text in the textbox or textarea, which gets into the 
> realm of the rich text box.

I think we should punt on this for now, since the browser vendors have 
been so slow at implementing Web Forms 2 -- no point getting so far ahead 
of them that they can't even fathom doing everything the spec says.

I expect what we'll eventually do is introduce an API to do context- 
sensitive styling of textarea contents, so you can do things like source 
code syntax highlighting. This would also take care of your use case.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:03:18 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:03:18 +0000 (UTC)
Subject: [whatwg] default select item that does not satisfy required
 attr.
In-Reply-To: <43FF2596.9040001@dolphinling.net>
References: <43FED100.3020308@cycloid.f9.co.uk>
	<43FF212A.2000907@dolphinling.net>
	<43FF2596.9040001@dolphinling.net>
Message-ID: <Pine.LNX.4.62.0901061153210.24109@hixie.dreamhostps.com>

On Fri, 24 Feb 2006, Ric Hardacre wrote:
>
> from the web forms doc in the comment at the bottom:
> 
>   * have a way of marking the first option of a <select> as the default
>     but have it not satisfy a new required="" attribute on <select> so
>     that you can have selects that require a valid value.
> 
> my proposed solution: [...]
> 
>  * A fairly common situation for web authors is to have two lists, where
>    the contents of the second depends on the value of the first. Is here
>    any way we could extend the current model to include this functionality?
>
> [...]

On Fri, 24 Feb 2006, dolphinling wrote:
> 
> [...]

I think the solutions proposed here (not quoted above for brevity) are 
interesting. However, I think, as with my earlier e-mail today, we should 
probably wait until the current crop of forms features is more widely 
implemented before adding more features. Thus, I haven't actually added 
these features yet.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:07:38 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:07:38 +0000 (UTC)
Subject: [whatwg] Form Serialization
In-Reply-To: <6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
References: <c9e12660708081342t1b319549kd6f42419f1996f48@mail.gmail.com>
	<6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>

On Wed, 8 Aug 2007, Garrett Smith wrote:
>
> It would be useful to have:
> 
>  HTMLFormElement.prototype.toJSONString
>  HTMLFormElement.prototype.getDataSetString

What are the use cases for this?


On Thu, 9 Aug 2007, Michael A. Puls II wrote:
> 
> Yes, these would be useful for 2 reasons that I can think of.
> 
> 1. *Potential* ease of working around form handling bugs when you
> really need to.
> Although if the form handling is broken, the methods might be too, but
> it still might be easier to get the broken data set and fix it instead
> of generating the data set yourself. At least with getDataString, it
> would show you what's going to be submitted.

Are browsers actually buggy here? Why would we not want the browser 
vendors to just fix those bugs rather than implement new ones?


> 2. Form handling extensions.
> 
> If you want to support the foobambang: protocol, you could use the 
> object and its array values to generate a foobambang:-conforming URI and 
> open it (using the default handler for foobambang URIs).

With the data: URL support, one can now do this using POST to a data: URL, 
per spec (just have the data: page redirect to the appropriate URL). Does 
this handle this case well-enough?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:23:10 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:23:10 +0000 (UTC)
Subject: [whatwg] Form Serialization
In-Reply-To: <c9e12660710022354m3cf40715t56c136243ca391d8@mail.gmail.com>
References: <c9e12660709111322v4668eb9fr7b43168d5d4a478d@mail.gmail.com>
	<op.tyzn3qfr5rel5w@quark>
	<c9e12660709221417j27e5af91y8b527374944d4a64@mail.gmail.com>
	<op.ty7gvrk05rel5w@eg10237.ad.ergogroup.no> <op.ty8942pekc4es2@quark>
	<c9e12660710022354m3cf40715t56c136243ca391d8@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0901061213410.24109@hixie.dreamhostps.com>


Sorry, missed this when writing my earlier reply.

On Fri, 10 Aug 2007, Garrett Smith wrote:
> 
> Why would anyone want to serialize a FORM?
> 
> FORMs are sometimes used for XMLHttpRequest.
> 
> Using a FORM for an XHR is a more explicit than hard coding the url and 
> params in the javascript. It's a good practice. It avoids the nastiness 
> of having the URL embedded in the script and shows just what arguments 
> (parameters) the method will take by exposing the remote method's 
> signature to the client side developer.
> 
> Form serialization by hand is not simple. That is why all the "ajax" 
> libs do it for you. So you get stuck using Dojo, or one of the other 
> libraries to do it for you. But then you have all the associated crud 
> with that library.

That could make sense, yes.

I've added a note to the spec about this use case. I haven't added the 
feature to the spec yet; I'd like to see more implementation experience 
with the rest of the forms features first.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:24:19 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:24:19 +0000 (UTC)
Subject: [whatwg] Old idea - can't find on issues list (or anywhere else)
In-Reply-To: <4781DA0E.3010709@dolphinling.net>
References: <4781DA0E.3010709@dolphinling.net>
Message-ID: <Pine.LNX.4.62.0901061223270.24109@hixie.dreamhostps.com>

On Mon, 7 Jan 2008, dolphinling wrote:
>
> Back in 2004, I sent an email about mutually exclusive sections in 
> forms, which was responded to as "a good idea, put on hold until WF3". 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-October/002285.html> 
> <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2004-November/002532.html>
> 
> I don't see this in the issues list or anywhere else on the site, and 
> while the comments at the end of WF2 mention some related ideas to 
> accomplish similar things, I don't see what I proposed.
> 
> So I just want to make sure it hasn't been lost in the years of work 
> that's gone on.

It's in the list of issues at the bottom of the spec, as:

 XXX * dolphinling suggests having a way to mark certain parts of a
       form as being dependent on another (mutually exclusive parts of
       a form)

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:32:50 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:32:50 +0000 (UTC)
Subject: [whatwg] <input placeholder="">
In-Reply-To: <a9699fd20812020318g7937a1fbtfa9920831a2e5015@mail.gmail.com>
References: <BAY109-F34060C84B5AB9C6274445FB41D0@phx.gbl>
	<op.tgvhccg3ir1lcs@daemontooth.bredbandsbolaget.se>
	<Pine.LNX.4.62.0810231147010.1237@hixie.dreamhostps.com>
	<39BEE8AF-F05F-44C3-8434-A8CA362F10F4@phroggy.com>
	<dd0fbad0810231219w2e885b38y8ab38ca9f2f57312@mail.gmail.com>
	<Pine.LNX.4.62.0811170238330.1237@hixie.dreamhostps.com>
	<0f7f0b616f8de6ff3395176311b72de0@myrealbox.com>
	<dd0fbad0811251324t5fc283e7w63e054ff69704686@mail.gmail.com>
	<Pine.LNX.4.62.0812021041100.17414@hixie.dreamhostps.com>
	<a9699fd20812020318g7937a1fbtfa9920831a2e5015@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0901061230340.24109@hixie.dreamhostps.com>

On Tue, 2 Dec 2008, Thomas Broyer wrote:
> On Tue, Dec 2, 2008 at 11:44 AM, Ian Hickson wrote:
> >
> > For <textarea>, a placeholder value seems odd. Do you have examples of 
> > people doing that?
> 
> Google Code hosting for adding a comment on an issue: 
> http://code.google.com/p/support/issues/detail?id=1#makechanges

Interesting.

I've added it to the list of missing features; I expect this might get 
added during the last call period (sometime next year maybe?) if browser 
vendors show an interest in implementing it. (Safari hasn't yet 
implemented it, and they invented placeholder="", so apparently one does 
not imply the other in terms of implementations.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan  6 04:40:48 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 12:40:48 +0000 (UTC)
Subject: [whatwg] <keygen>
In-Reply-To: <013e01c90cff$f3971b50$82c5a8c0@arport2v>
References: <017101c90c0b$6435a2a0$82c5a8c0@arport2v>
	<8f2fc6f50809012334m36bcb255h81e4edfb878525f@mail.gmail.com>
	<002501c90cd3$82d06ce0$82c5a8c0@arport2v>
	<8f2fc6f50809020256l798088a5q5c3aa75d59c16962@mail.gmail.com>
	<013e01c90cff$f3971b50$82c5a8c0@arport2v>
Message-ID: <Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>


Over the years, several people (most of them bcc'ed) have asked for HTML5 
to include a definition of <keygen>. Some have even gone as far as finding 
documentation on the element -- thank you.

As I understand it based on the documentation, <keygen> basically 
generates a public/private asymmetric cryptographic key pair, and then 
sends the public component as its form value.

Unfortunately, this seems completely and utterly useless, as at no point 
does there seem to be any way to ever use the private component either for 
signing or for decrypting anything, nor does there appear to be a way to 
use the certificate for authentication.

Without further information along these lines describing how to actually 
make practical use of the element, I do not intend to document <keygen> in 
the HTML5 specification. If anyone can fill in these holes that would be 
very helpful.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From sunberg at gmail.com  Tue Jan  6 05:12:23 2009
From: sunberg at gmail.com (Lars)
Date: Tue, 6 Jan 2009 14:12:23 +0100
Subject: [whatwg] <keygen>
In-Reply-To: <Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
References: <017101c90c0b$6435a2a0$82c5a8c0@arport2v>
	<8f2fc6f50809012334m36bcb255h81e4edfb878525f@mail.gmail.com>
	<002501c90cd3$82d06ce0$82c5a8c0@arport2v>
	<8f2fc6f50809020256l798088a5q5c3aa75d59c16962@mail.gmail.com>
	<013e01c90cff$f3971b50$82c5a8c0@arport2v>
	<Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
Message-ID: <8f2fc6f50901060512i1e9100b0y539dfd2f39f5aa2a@mail.gmail.com>

Hi

I have written some documentation on this before, and I have already
published it to this mailing list. You can find it at
http://phpmylogin.sourceforge.net/wiki/doku.php?id=keygen_attribute if
its nowhere to be found....

The private/public keypair generated with the keygen tag is only
useful if you have configured your webserver to only allow
certificates signed by your CA. I know of a few netbanks that does it
this way. Its a very secure solution!

If you want, I can send you some more php code of how I implemented
this in one of my projects. I can also make a little test-case if that
would be better..

Thanks for bringing up this subject again!

Cheers
  Lars

On Tue, Jan 6, 2009 at 1:40 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> Over the years, several people (most of them bcc'ed) have asked for HTML5
> to include a definition of <keygen>. Some have even gone as far as finding
> documentation on the element -- thank you.
>
> As I understand it based on the documentation, <keygen> basically
> generates a public/private asymmetric cryptographic key pair, and then
> sends the public component as its form value.
>
> Unfortunately, this seems completely and utterly useless, as at no point
> does there seem to be any way to ever use the private component either for
> signing or for decrypting anything, nor does there appear to be a way to
> use the certificate for authentication.
>
> Without further information along these lines describing how to actually
> make practical use of the element, I do not intend to document <keygen> in
> the HTML5 specification. If anyone can fill in these holes that would be
> very helpful.
>
> Cheers,
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>


From derhoermi at gmx.net  Tue Jan  6 05:16:04 2009
From: derhoermi at gmx.net (Bjoern Hoehrmann)
Date: Tue, 06 Jan 2009 14:16:04 +0100
Subject: [whatwg] <keygen>
In-Reply-To: <Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
References: <017101c90c0b$6435a2a0$82c5a8c0@arport2v>
	<8f2fc6f50809012334m36bcb255h81e4edfb878525f@mail.gmail.com>
	<002501c90cd3$82d06ce0$82c5a8c0@arport2v>
	<8f2fc6f50809020256l798088a5q5c3aa75d59c16962@mail.gmail.com>
	<013e01c90cff$f3971b50$82c5a8c0@arport2v>
	<Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
Message-ID: <1dl6m4dbinmdg3o0jtjou17qm1n57g66q9@hive.bjoern.hoehrmann.de>

* Ian Hickson wrote:
>Over the years, several people (most of them bcc'ed) have asked for HTML5 
>to include a definition of <keygen>. Some have even gone as far as finding 
>documentation on the element -- thank you.
>
>As I understand it based on the documentation, <keygen> basically 
>generates a public/private asymmetric cryptographic key pair, and then 
>sends the public component as its form value.
>
>Unfortunately, this seems completely and utterly useless, as at no point 
>does there seem to be any way to ever use the private component either for 
>signing or for decrypting anything, nor does there appear to be a way to 
>use the certificate for authentication.

You don't say which documentation you read, but the original Netscape
documentation was rather clear that the private component is stored in
the local keystore, and from there you can of course use it when a site
requests that you identify yourself with a certificate.

http://developer.netscape.com/docs/manuals/htmlguid/tags10.htm once had:

  The KEYGEN tag facilitates the generation of key material and 
  submission of the public key as part of an HTML form. This mechanism
  is designed for use in web-based certificate management systems. It
  displays a menu of key-size choices from which the user must choose
  one. Then, when the submit button is clicked, a key pair of the
  selected size is generated. The private key is encrypted and stored in
  the local key database.
-- 
Bj?rn H?hrmann ? mailto:bjoern at hoehrmann.de ? http://bjoern.hoehrmann.de
Am Badedeich 7 ? Telefon: +49(0)160/4415681 ? http://www.bjoernsworld.de
25899 Dageb?ll ? PGP Pub. KeyID: 0xA4357E78 ? http://www.websitedev.de/ 


From shadow2531 at gmail.com  Tue Jan  6 06:21:56 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Tue, 06 Jan 2009 09:21:56 -0500
Subject: [whatwg] Form Serialization
In-Reply-To: <Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>
References: <c9e12660708081342t1b319549kd6f42419f1996f48@mail.gmail.com>
	<6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
	<Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>
Message-ID: <op.unb96td11ejg13@sandra-svwliu01>

On Tue, 06 Jan 2009 07:07:38 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 8 Aug 2007, Garrett Smith wrote:
>>
>> It would be useful to have:
>>
>>  HTMLFormElement.prototype.toJSONString
>>  HTMLFormElement.prototype.getDataSetString
>
> What are the use cases for this?
>
>
> On Thu, 9 Aug 2007, Michael A. Puls II wrote:
>>
>> Yes, these would be useful for 2 reasons that I can think of.
>>
>> 1. *Potential* ease of working around form handling bugs when you
>> really need to.
>> Although if the form handling is broken, the methods might be too, but
>> it still might be easier to get the broken data set and fix it instead
>> of generating the data set yourself. At least with getDataString, it
>> would show you what's going to be submitted.
>
> Are browsers actually buggy here?

Just Opera with action="mailto:". And, other browsers have differences with action="mailto:" that could be sorted out. HTML5 takes care of this, but fixing everything now would be easier if there was a getDataString.

But that's just a current example that should go away. But, later on, if getDataString was available, and there was some other issue, it could help make things easier to fix.

Also, I just always thought it was odd that you couldn't *directly* check what the browser was going to submit. I like a little transparency here. May want to modify the dataset before it goes out.

A while back, Opera (I think 8.x maybe) would submit the full path of an <input type="file" even though it would only provide the filename through input.value in JS. I, and some others, would browse to a local media file, submit the form to an iframe and get its src just to get the full pathname of the media file so the path could be added to the wmp plug-in's playlist via its scripting api. It was basically a local media player web page app. Getting a hold of the form dataset proved to be a good workaround.

There were other examples, but they escape me atm.

You probably won't buy it, but I like the idea of using a form as a user input data gatherer for in-page js-based apps where you do custom things with the data and often don't actually submit the data anywhere.

> Why would we not want the browser
> vendors to just fix those bugs rather than implement new ones?

If the vendor agrees it's bug, plans to fix it and can do it in a timely manner, sure. Otherwise, you get people to starting fixing things themselves (js libs do that in a way).

>> 2. Form handling extensions.
>>
>> If you want to support the foobambang: protocol, you could use the
>> object and its array values to generate a foobambang:-conforming URI and
>> open it (using the default handler for foobambang URIs).
>
> With the data: URL support, one can now do this using POST to a data:  
> URL,
> per spec (just have the data: page redirect to the appropriate URL). Does
> this handle this case well-enough?
>


<form action="data:text/html;charset=utf-8,%3Cscript%3Ealert(%22%%%22)%3C%2Fscript%3E" method="post">
    <input name="one" value="zip zam bam">
    <input name="two" value="meow bark quack">
    <button>submit</submit>
</form>

Looking at the spec, it looks like submitting that would alert "one=zip%20zam%20bam&two=meow%20bark%20quack". If so, I guess that could work for getting the dataset. But then, the  dataset is in a different page than the form.

I'm thinking more of:

form.addEventListener("submit", function(e) {
    e.preventDefault();
    alert(e.target.getDataset());
    // Do whatever custom stuff with the data I want
}, false);

Might even might form submit to XHR simpler code-wise.

-- 
Michael




From webmaster at keryx.se  Tue Jan  6 09:52:03 2009
From: webmaster at keryx.se (Keryx Web)
Date: Tue, 06 Jan 2009 18:52:03 +0100
Subject: [whatwg] Link errors in spec
Message-ID: <49639A43.2080403@keryx.se>

Hi and happy new year

http://wiki.whatwg.org/wiki/Differences_from_HTML4#Dropped_Attributes

All links here are defective, e.g. #the-area should be #the-area-element

etc.


Lars Gunther


From annevk at opera.com  Tue Jan  6 11:36:42 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 06 Jan 2009 20:36:42 +0100
Subject: [whatwg] Link errors in spec
In-Reply-To: <49639A43.2080403@keryx.se>
References: <49639A43.2080403@keryx.se>
Message-ID: <op.uncorgfb64w2qv@annevk-t60.oslo.opera.com>

On Tue, 06 Jan 2009 18:52:03 +0100, Keryx Web <webmaster at keryx.se> wrote:
> http://wiki.whatwg.org/wiki/Differences_from_HTML4#Dropped_Attributes
>
> All links here are defective, e.g. #the-area should be #the-area-element

1. It's a wiki. Either fix the bug directly or mention it on the talk page  
;-)

2. That particular wiki page is an old draft for  
http://dev.w3.org/html5/html4-differences/ although both are currently out  
of date.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From mjs at apple.com  Tue Jan  6 11:41:13 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 06 Jan 2009 11:41:13 -0800
Subject: [whatwg] <keygen>
In-Reply-To: <Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
References: <017101c90c0b$6435a2a0$82c5a8c0@arport2v>
	<8f2fc6f50809012334m36bcb255h81e4edfb878525f@mail.gmail.com>
	<002501c90cd3$82d06ce0$82c5a8c0@arport2v>
	<8f2fc6f50809020256l798088a5q5c3aa75d59c16962@mail.gmail.com>
	<013e01c90cff$f3971b50$82c5a8c0@arport2v>
	<Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
Message-ID: <39804F4C-9EB3-44AE-ACA8-36BF9C849061@apple.com>


On Jan 6, 2009, at 4:40 AM, Ian Hickson wrote:

>
> Over the years, several people (most of them bcc'ed) have asked for  
> HTML5
> to include a definition of <keygen>. Some have even gone as far as  
> finding
> documentation on the element -- thank you.
>
> As I understand it based on the documentation, <keygen> basically
> generates a public/private asymmetric cryptographic key pair, and then
> sends the public component as its form value.
>
> Unfortunately, this seems completely and utterly useless, as at no  
> point
> does there seem to be any way to ever use the private component  
> either for
> signing or for decrypting anything, nor does there appear to be a  
> way to
> use the certificate for authentication.
>
> Without further information along these lines describing how to  
> actually
> make practical use of the element, I do not intend to document  
> <keygen> in
> the HTML5 specification. If anyone can fill in these holes that  
> would be
> very helpful.

In the case of Safari, we store the generated private key in the  
Keychain, and sites using <keygen> typically respond with a signed  
certificate, which is downloaded and automatically added to the  
Keychain. Depending on the valid purposes of the key, users can then  
do the following automatically:

1) Browse to SSL sites that require client-side certificates for  
authentication, in Safari.
2) Send email with strong authentication via a cryptographic  
signature, in Mail.
3) Receive encrypted email from users who have received a copy of  
their public key, in Mail.

I imagine other browsers store the private key and received signed  
certificate in similar ways.

This is certainly a useful feature, and we added it at the request of  
both end users and CAs.

Regards,
Maciej



From mart at degeneration.co.uk  Tue Jan  6 11:51:54 2009
From: mart at degeneration.co.uk (Martin Atkins)
Date: Tue, 06 Jan 2009 11:51:54 -0800
Subject: [whatwg] <keygen>
In-Reply-To: <39804F4C-9EB3-44AE-ACA8-36BF9C849061@apple.com>
References: <017101c90c0b$6435a2a0$82c5a8c0@arport2v>	<8f2fc6f50809012334m36bcb255h81e4edfb878525f@mail.gmail.com>	<002501c90cd3$82d06ce0$82c5a8c0@arport2v>	<8f2fc6f50809020256l798088a5q5c3aa75d59c16962@mail.gmail.com>	<013e01c90cff$f3971b50$82c5a8c0@arport2v>	<Pine.LNX.4.62.0901061233590.24109@hixie.dreamhostps.com>
	<39804F4C-9EB3-44AE-ACA8-36BF9C849061@apple.com>
Message-ID: <4963B65A.4080905@degeneration.co.uk>

Maciej Stachowiak wrote:
> 
> In the case of Safari, we store the generated private key in the 
> Keychain, and sites using <keygen> typically respond with a signed 
> certificate, which is downloaded and automatically added to the 
> Keychain. Depending on the valid purposes of the key, users can then do 
> the following automatically:
> 
> 1) Browse to SSL sites that require client-side certificates for 
> authentication, in Safari.
[snip]

In case it's useful, an example of the above use-case is 
http://www.myopenid.com/ , which is an OpenID provider that can use SSL 
client certs for authentication. The client certs are initially issued 
using <keygen>.

I personally use it in Opera and Firefox, and they act in a similar way 
to what you describe for Safari.



From ian at hixie.ch  Tue Jan  6 14:07:00 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Jan 2009 22:07:00 +0000 (UTC)
Subject: [whatwg] Form Serialization
In-Reply-To: <op.unb96td11ejg13@sandra-svwliu01>
References: <c9e12660708081342t1b319549kd6f42419f1996f48@mail.gmail.com>
	<6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
	<Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>
	<op.unb96td11ejg13@sandra-svwliu01>
Message-ID: <Pine.LNX.4.62.0901062204060.18598@hixie.dreamhostps.com>

On Tue, 6 Jan 2009, Michael A. Puls II wrote:
> > 
> > Are browsers actually buggy here?
> 
> You probably won't buy it, but I like the idea of using a form as a user 
> input data gatherer for in-page js-based apps where you do custom things 
> with the data and often don't actually submit the data anywhere.

Oh this is quite common, I'm just not entirely sure that the form data set 
serialised is a good way of handling that data.

However, I've added it to the list of missing features; once browsers are 
more consistent with their forms handling we can consider adding it then.


> > Why would we not want the browser vendors to just fix those bugs 
> > rather than implement new ones?
> 
> If the vendor agrees it's bug, plans to fix it and can do it in a timely 
> manner, sure. Otherwise, you get people to starting fixing things 
> themselves (js libs do that in a way).

Well if the browser vendors don't agree it's a bug, they might not agree 
that this is a feature worth implementing either. If they don't have the 
time to fix the bug, they might not have the time to implement this 
feature either. And if they do implement this feature, it'll likely have 
the same bug since it would just be exposing the same code.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From t.broyer at ltgt.net  Tue Jan  6 15:15:44 2009
From: t.broyer at ltgt.net (Thomas Broyer)
Date: Wed, 7 Jan 2009 00:15:44 +0100
Subject: [whatwg] Cookie-based HTTP Authentication
	(draft-broyer-http-cookie-auth-00)
In-Reply-To: <a9699fd20901041625j68bcdf01h1bc6430f803c73dc@mail.gmail.com>
References: <a9699fd20901041625j68bcdf01h1bc6430f803c73dc@mail.gmail.com>
Message-ID: <a9699fd20901061515p48dcc77fl7bb387aed16e5cbd@mail.gmail.com>

On Mon, Jan 5, 2009 at 1:25 AM, Thomas Broyer wrote:
>
> As I previously said, I spent some holiday time to put my thoughts
> about "RFC2617-compliant cookie-based authentication" into an Internet
> Draft.

A collegue of mine told me I forgot to include a direct link to the draft.
Here it is (for those not used to IETF I-Ds' URLs):
http://www.ietf.org/internet-drafts/draft-broyer-http-cookie-auth-00.txt

I've put an HTML version here:
http://ltgt.net/projects/http-cookie-auth/draft-broyer-http-cookie-auth-00.html

As a side note, I've moved my Mercurial repository from broyer.info to
hg.ltgt.net (you'll be automatically redirected).
And my apologies to Julian and others as the -00 draft doesn't include
acknowledgements (fixed in the repo)

-- 
Thomas Broyer


From shadow2531 at gmail.com  Tue Jan  6 21:11:07 2009
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Wed, 07 Jan 2009 00:11:07 -0500
Subject: [whatwg] Form Serialization
In-Reply-To: <Pine.LNX.4.62.0901062204060.18598@hixie.dreamhostps.com>
References: <c9e12660708081342t1b319549kd6f42419f1996f48@mail.gmail.com>
	<6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
	<Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>
	<op.unb96td11ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0901062204060.18598@hixie.dreamhostps.com>
Message-ID: <op.undfctad1ejg13@sandra-svwliu01>

On Tue, 06 Jan 2009 17:07:00 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 6 Jan 2009, Michael A. Puls II wrote:
>> >
>> > Are browsers actually buggy here?
>>
>> You probably won't buy it, but I like the idea of using a form as a user
>> input data gatherer for in-page js-based apps where you do custom things
>> with the data and often don't actually submit the data anywhere.
>
> Oh this is quite common, I'm just not entirely sure that the form data  
> set
> serialised is a good way of handling that data.

I see. It might be better if there was a getFormData() that returned:

{
    "name1" : ["value1", "value2"],
    "name2" : ["value1", "value2"],
};

Or, for exact order of a appearance in the <form> with duplicates flat-like:

[
    {"name1" : "value1"},
    {"name2" : "value1"},
    {"name2" : "value2"},
    {"name1" : "value2"}
];
(Kind of like vector<pair<string, string> >)

Not sure if you'd want it to produce:

{"image1" : "file.png"}

or something like:

{"image1" : {"file.png" : "data:image/png,base64... }}

or both depending on an option and the form method. But, just mentioning it.

> However, I've added it to the list of missing features; once browsers are
> more consistent with their forms handling we can consider adding it then.

O.K.

>> > Why would we not want the browser vendors to just fix those bugs
>> > rather than implement new ones?
>>
>> If the vendor agrees it's bug, plans to fix it and can do it in a timely
>> manner, sure. Otherwise, you get people to starting fixing things
>> themselves (js libs do that in a way).
>
> Well if the browser vendors don't agree it's a bug, they might not agree
> that this is a feature worth implementing either. If they don't have the
> time to fix the bug, they might not have the time to implement this
> feature either.

Yep, true.

> And if they do implement this feature, it'll likely have
> the same bug since it would just be exposing the same code.

True. Depending on the bug though, you might be able to doctor up the broken dataset before it goes out to workaround the bug.

I'll try to implement a getFormData() in JS how I think it should be while trying to follow the spec and provide feedback.

-- 
Michael




From dhtmlkitchen at gmail.com  Tue Jan  6 22:02:13 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Tue, 6 Jan 2009 22:02:13 -0800
Subject: [whatwg] Form Serialization
In-Reply-To: <op.undfctad1ejg13@sandra-svwliu01>
References: <c9e12660708081342t1b319549kd6f42419f1996f48@mail.gmail.com>
	<6b9c91b20708091921y1148c3b7r7c814e35cfe59c29@mail.gmail.com>
	<Pine.LNX.4.62.0901061203400.24109@hixie.dreamhostps.com>
	<op.unb96td11ejg13@sandra-svwliu01>
	<Pine.LNX.4.62.0901062204060.18598@hixie.dreamhostps.com>
	<op.undfctad1ejg13@sandra-svwliu01>
Message-ID: <c9e12660901062202h10a57984u164301c2ee7c0829@mail.gmail.com>

On Tue, Jan 6, 2009 at 9:11 PM, Michael A. Puls II <shadow2531 at gmail.com> wrote:
> On Tue, 06 Jan 2009 17:07:00 -0500, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Tue, 6 Jan 2009, Michael A. Puls II wrote:
>>>
>>> >
>>> > Are browsers actually buggy here?
>>>
>>> You probably won't buy it, but I like the idea of using a form as a user
>>> input data gatherer for in-page js-based apps where you do custom things
>>> with the data and often don't actually submit the data anywhere.
>>
>> Oh this is quite common, I'm just not entirely sure that the form data set
>> serialised is a good way of handling that data.
>
Extremely common.

There are more than one way to handle this, potentially. Submit a FORM
to XHR, for one.

Serialize a form is possible today and it works. It just doesn't work
natively. Well, it does, we just can't get at that serialized value.

> I see. It might be better if there was a getFormData() that returned:
>
> {
>   "name1" : ["value1", "value2"],
>   "name2" : ["value1", "value2"],
> };
>

That is the basis for all most form serializers.

>
> {"image1" : {"file.png" : "data:image/png,base64... }}
>

Synchronous client-side reads are apparently not going to be a part of
form serialization. What do you do with input type="file"? Sending the
name is pretty useless.

[snip]

>
> I'll try to implement a getFormData() in JS how I think it should be while
> trying to follow the spec and provide feedback.
>

Tips:

 * If a button submitted the form, it is not included in
serialization. Opera, onsubmit, the event.relatedTarget is the submit
button (nonstandard). The submit button that was clicked should be
included[1].

 *  input type="image" is not included in the elements collection and
is not included in the serialization in Form.js. The x/y coordinates
don't matter much (you don't need them).

A form serializer should follow the guidelines on successful form controls[1].

In case it isn't obvious, the form controls should not be accessed
directly off the form, e.g. form.controlName (error-prone). Instead
the elements collection should be used, e.g.
form.elements.controlName.

Garrett

[1]http://www.w3.org/TR/html401/interact/forms.html#h-17.13.2
[2]http://jibbering.com/faq/names/


From annevk at opera.com  Wed Jan  7 05:33:58 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Wed, 07 Jan 2009 14:33:58 +0100
Subject: [whatwg] Web Workers: minor issues
Message-ID: <op.und2mwc064w2qv@annevk-t60.oslo.opera.com>

showNotification is no longer part of HTML5.

The SharedWorker IDL block uses <code>. That should probably be <span>.

Why is everything a NoInterfaceObject? Doesn't that mean that you can no  
longer prototype them?


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From chaals at opera.com  Wed Jan  7 16:37:50 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Thu, 08 Jan 2009 11:37:50 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <3B7AFD76-6ED1-4014-8532-64EE32BD4569@iki.fi>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan>
	<dd0fbad0901020849w12e7a381y5256082cc4027109@mail.gmail.com>
	<495E552B.5070004@gmx.de>
	<dd0fbad0901021029o46e7988cmeb2815261affe509@mail.gmail.com>
	<495F61FA.50405@gmx.de> <495F7EB2.2070805@danbri.org>
	<3B7AFD76-6ED1-4014-8532-64EE32BD4569@iki.fi>
Message-ID: <op.unexdcrtwxe0ny@widsith.local>

On Mon, 05 Jan 2009 00:17:39 +1100, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Jan 3, 2009, at 17:05, Dan Brickley wrote:
>
>> But perhaps a more practical concern is that it unfairly biases things  
>> towards popular languages - lucky English, lucky Spanish, etc., and  
>> those that lend themselves more to NLP analysis. The Web is for  
>> everyone, and people shouldn't be forced to read and write English to  
>> enjoy the latest advances in Web automation.
>
> Some languages are higher in the pecking order than others when software  
> development is prioritized, and RDFa cannot level the playing field here.
>
> Suppose there's a use case that can be satisfactorily addressed by  
> applying NLP heuristics to content for the top-tier languages. Even if  
> there were an RDF mechanism for addressing the same use case without  
> relying on natural language, software aimed for serving the top-tier  
> languages would still do the NLP thing for the use case.

No. There is no reason for most developers to prefer one over the other  
under the circumstances described.

Clearly Google has an investment in text-harvesting in a bunch of  
languages. Equally clearly its competitors who are more sucessfeul in  
various languages (Yandex, Baidu, etc) have an investment in the  
technology they use.

But developing a new indexing process, there is no a priori reason to  
favour NLP over some other technique that is also satisfactory, and if you  
happen to be interested in a global market, it makes sense to develop a  
system that can be more easily adapted, other things being equal.
...
> Instead of bearing the cost of developing a totally alternative  
> technology stack for the other languages without benefiting from any  
> spillover from the effort done for the top-tier languages, it makes more  
> sense to invest the effort into building upon the reusable parts already  
> developed for the top-tier languages.

Except that it turns out that the re-usable parts of most search engines,  
for the general developer, are pretty limited. Whereas the re-usable parts  
of the RDF stack are numerous, available for many different platforms,  
 from GPL open source to bespoke commercial closed-source and everything  
between.

All this does not necessarily establish the case for using RDF in HTML, it  
is just meant to demonstrate that this particular case *against* doesn't  
seem to be established, to me.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From webmaster at mithgol.ru  Wed Jan  7 23:14:16 2009
From: webmaster at mithgol.ru (Mithgol the Webmaster)
Date: Thu, 8 Jan 2009 10:14:16 +0300
Subject: [whatwg] [WhatWG] Some additional API is needed for sites to see
	whether registerProtocolHandler() call was successful
Message-ID: <928315030.20090108101416@mithgol.ru>

In the year 2007 or 2008 the site http://fghi.pp.ru/ was launched to
act as a gate between the Fidonet echomail system and the Web browsers
like Firefox. For example, for people who not have direct access to
Fidonet and thus cannot open the Fidonet message that has the URL

    area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

it is still possible for them to use the Web gate by using the URL

    http://fghi.pp.ru/?area://Ru.Blog.Mithgol?msgid=2:5063/88+49659a64

This gate handles several FGHI URI schemes such as area:// and fecho://
for Fidonet hyperlinks.

And then (though already several months ago), Firefox 3.0.x appeared, the
browser that implemented WhatWG proposal of registerProtocolHandler() API.
It then became possible for web sites to register themselves as handlers
for URL schemes previously unknown to Web browsers. Schemes like FGHI
URLs of Fidonet that previously remained unknown to the browsers of
Internet, though they are gradually implemented in more and more
browsers of Fidonet, such as HellEd and NoSFeRaTU's GoldED+.

I immediately wrote a Fidonet echomail message to the FGHI URL gate's
author and explained the advantages of registerProtocolHandler():

    area://GanjaNet.Local?msgid=2:5063/88+48319a1f

Then the FGHI URL gate's author created http://fghi.pp.ru/handler.php
as the page that anyone may visit and register the gate as a handler
for area:// and fecho:// hyperlinks in Firefox.

However, even after such registration is complete, the reader visits
the pages such as http://fghi.pp.ru/?area://FTSC_Public/ and there
encounters Fidonet URLs in their gated form, like the following:

    http://fghi.pp.ru/?area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

I asked the gate's author why the URLs are not provided then in their
natural Fidonet form, like the following:

    area://FTSC_PUBLIC?msgid=2:280/5555+48c0e781

The gate's author then explained to me that the WhatWG API is not
complete and does not provide the site with any means to determine
whether registerProtocolHandler() call was successful and whether the
URL scheme was actually registered, and whether it remains registered
when the page is served by the server.

I hereby ask the WhatWG team to think of some additional API in order
for this task to be handled as well.

The HTML5 standard function registerProtocolHandler() should probably
remain void as in standard, but WhatWG could invent yet another
boolean protocolRegistered("area"), with the only argument (protocol
name as string), to check whether a protocol is registered.

See http://www.whatwg.org/specs/web-apps/current-work/#custom-handlers
section 5.6.1.1 for the list of possible security implications. Take
the following two thoughts into your consideration:

1) The browser should prevent continous registration spamming,
   i.e. a site should not harm its reader (the user) even if the site
   decides to repeat registerProtocolHandler() until
   protocolRegistered() returns true. At http://fghi.pp.ru/handler.php
   I already noticed that Firefox already shows its notifications
   one after another ("fecho://" after "area://" only if "area://" was
   registered or cancelled by the user); that's probably enough.

2) A site should be prevented from being able to bargain for protocol
   registering, e.g. the scenario "in order to login for porn,
   register your mailto handler here and allow us to harvest your
   addressees for spam" should not be made possible. A mere checkbox
   ("I register evil.example.org as a handler for mailto links that
   appear on the pages of evil.example.org only.") should be enough
   for the site to see protocolRegistered() as true and even verify
   that a "mailto:example at evil.example.org" link, when clicked on the
   evil site, leads to the same site's handler page, but no other harm
   would occur.

Yet another thought to clarify: protocolRegistered("area") could
return not just boolean true but a string such as
"http://fghi.pp.ru/?%s". However, that would be likely to leak
intranet structure (of handler pages) to the outworld, and would also
encourage handler sites to use their own prefixes to non-standard URLs
even when they could use such URLs directly (but when that would
direct their user to a rival handler site that the user prefers).
That's an obvious Bad Thing, so I suggest only a boolean
protocolRegistered() function here.


-- 
Best regards,
 Mithgol                          mailto:webmaster at mithgol.ru



From henry.story at bblfish.net  Thu Jan  8 15:28:44 2009
From: henry.story at bblfish.net (Story Henry)
Date: Fri, 9 Jan 2009 00:28:44 +0100
Subject: [whatwg] <keygen>
Message-ID: <C3CC87D2-2781-4F23-953B-FBD48639E556@bblfish.net>

Dear WhatWG,

I just subscribed to this list having noticed a thread earlier this  
month on the topic of the <keygen> tag. As it happens we are working  
on a protocol
foaf+ssl where keygen turns out to be extremely useful. It allows us  
to create web services to give people very secure certificates which  
can then be used to build a secure distributed social network based on  
a web of trust.

The foaf+ssl protocol works as it happens with most existing browsers  
- though we have not done a detailed study of this yet (if people  
could help this would be greatly appreciated). The protocol is  
summarized here:

http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html

And you can find more on my blog at http://blogs.sun.com/bblfish .

The discussion on <keygen> which produces spkac public keys which it  
sends to the server can be found on the foaf-protocols mailing list  
archive under 'spkac'

http://lists.foaf-project.org/pipermail/foaf-protocols/2009-January/date.html

To tell you the truth I just discovered this tag recently myself,  
wrote some code to test that it worked, found it to work on Opera,  
Netscape, and Firefox, though it works slightly differently on each  
platform.

http://lists.foaf-project.org/pipermail/foaf-protocols/2009-January/000153.html

I also put up a page on wikipedia:

	http://en.wikipedia.org/wiki/Spkac

So please do keep the tag, and perhaps work on making it easier to  
work with.

	Henry

Blog: http://blogs.sun.com/bblfish


Ian Hickson wrote on January 6 2009:
> Over the years, several people (most of them bcc'ed) have asked for  
> HTML5 to include a definition of <keygen>. Some have even gone as  
> far as finding documentation on the element -- thank you. As I  
> understand it based on the documentation, <keygen> basically  
> generates a public/private asymmetric cryptographic key pair, and  
> then sends the public component as its form value.  Unfortunately,  
> this seems completely and utterly useless, as at no point does there  
> seem to be any way to ever use the private component either for  
> signing or for decrypting anything, nor does there appear to be a  
> way to use the certificate for authentication. Without further  
> information along these lines describing how to actually make  
> practical use of the element, I do not intend to document <keygen>  
> in the HTML5 specification. If anyone can fill in these holes that  
> would be very helpful. Cheers,






From alex.baldacchino at email.it  Thu Jan  8 17:54:08 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 09 Jan 2009 02:54:08 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um7lz7ufwxe0ny@widsithpro.lan>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>
	<495F97A9.1080602@email.it> <op.um7lz7ufwxe0ny@widsithpro.lan>
Message-ID: <4966AE40.3040600@email.it>

Charles McCathieNevile ha scritto:
> On Sun, 04 Jan 2009 03:51:53 +1100, Calogero Alex Baldacchino 
> <alex.baldacchino at email.it> wrote:
>
>> Charles McCathieNevile ha scritto:
>> ... it shouldn't be too difficoult to create a custom parser, 
>> comforming to RDFa spec and availing of data-* attributes...
>>
>> That is, since RDFa can be "emulated" somehow in HTML5 and tested 
>> without changing current specification, perhaps there isn't a strong 
>> need for an early adoption of the former, and instead an "emulated" 
>> mergence might be tested first within current timeline.
>
> In principle this is possible. But the data-* attributes are designed 
> for private usage, and introducing a public usage means creating a 
> risk of clashes that pollute RDFa data gathered this way. In other 
> words, this is indeed feasible, but one would expect it to show that 
> the data generated was unreliable (unless privately nobody is 
> interested in basic terms like about). 

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 dataset would give 
access to "rdfa-about", instead of just "about", that is using the 
prefix "rdfa-" as acting as a namespace prefix in xml (hence, as if 
there were "rdfa:about" instead of "data-rdfa-about" in the markup).

This way, the public exposure of RDFa attributes on top of the generic 
and normally-private dataset feature might be enough circumscribed to 
avoid clashes. That is, if RDFa shows its best benefits when used to 
address small-scale needs involving trusted/reliable (meta-)data, it 
should be fair to assume all involved parties are aware that each one is 
using RDFa, and aren't just running an RDFa processor in the hope to 
gather enough informations.

 From this point of view, it should be quite unlike to find people using 
"data-rdfa-about" to express different semantics in the same page 
(whereas data-property might cause ambiguity, for instance), as well as 
it is (or should be) quite unlike to find namespaces using the very same 
prefix involved in the same xml document (that is, I think choosing a 
name including a namespace prefix for a data-* attribute (and also for a 
class in a generic container as a div or a span, to tell it represents 
an external element) can replicate quite safely the xml extensibility 
for custom uses, to some extent, without requiring a wide support for it 
in text/html document - since it seems that xhtml extensibility is not a 
major concern, at least not enough to be worth merging it into html).

Just an idea, though.

However, AIUI, actual xml serialization (xhtml5) allows the use of 
namespaces and prefixed attributes, thus couldn't a proper namespace be 
introduced for RDFa attributes, so they can be used, if needed, in 
xhtml5 documents? I think such might be a valuable choice, because it 
seems to me RDFa attributes can be used to address such cases where 
metadata must stay as close as possible to correspondent data, but a 
mistake in a piece of markup may trigger the adoption agency or foster 
parenting algorithms, eventually causing a separation between metadata 
and content, thus possibly breaking reliability of gathered 
informations. From this perspective, a parser stopping on the very first 
error might give a quicker feedback than one rearranging misnested 
elements as far as it is reasonably possible (not affecting, and instead 
improving, content presentation and users' "direct" experience, but 
possibly causing side-effects with metadata).

Also, if the above is true, using namespaced and prefixed attributes 
instead of ones laying in the same namespace shared both by html5 and by 
xhtml5 (in theory) might prevent the use of such metadata in a document 
whose parsing rules might lead to possible side-effects.

> Such results have been used to suggest that poorly implemented 
> features should be dropped, but this hypothetical case suggests to me 
> that the argument is wrong, and that if in the face of reasons why the 
> data would be bad people use them, one might expect better usage by 
> formalising the status of such features and getting decent 
> implementations.
>

Generally speaking, I think reasoning in terms of "poor implementation" 
vs "rare usage" is quite like moving as a dog biting his own tail, 
because poorly implemented features are forcedly rarely used, and rarely 
used features can't convince UAs developers to implement them (in 
general). But, if a feature is widely needed, several hacks may born, 
thus providing an evidence of a global problem to be solved in a certain 
manner by implementing a certain, well-conceived feature.

As far as I've understood it, that's the main guideline to change actual 
specification, which is moving on the base of a bullet-tracing evolution 
(perhaps weighted on the need for completely new features, as a balance 
between the need for innovation and that for backward compatibility), 
rather than a "cathedral-wise" definition of what is or can be a useful 
feature to be implemented. For this reason, I think that mapping RDFa 
attributes on data-rdfa-* attributes to experiment a convergence between 
RDFa attributes and html5 specific features might be a start point to 
get RDFa attributes both specified and widely supported by 
implementations (either as they're defined in W3C Recommendation, or in 
the form of data-rdfa-*, hence dealt with differently from data-* 
attributes, for backward compatibility with such early implementations - 
a slightly different (or somehow prefixed) name shouldn't be much of a 
problem, as far as the name is not a problem per se (e.g. it is not 
prone to clashes) and allows a one-to-one correspondence).

However, if a custom/small scale solution met a wide support and a deep 
integration into major browsers, maybe misuses and abuses (which a 
proper formalisation couldn't prevent) might become widespread, thus 
making disadvantages (appear or be) greater than advantages, if measured 
on a wider scale (the same as the implementation). Therefore, I think a 
good start point can consist of partly introducing support on top of 
existing features (in the case of RDFa, either through well-groomed, 
custom data-* attributes in html5, or by defining a proper namespace 
with a proper prefix for xhtml5), without requiring a deep integration 
of a processor for the new feature, but instead letting it be a (custom) 
plugin/extension, or an api for a (custom) web application needing it - 
since a person just wishing to get access to some content without caring 
of metadata and metadata reliability could just visit a page, while an 
organisation wishing to interchange RDFa modelled data with another one 
can run a separate processor (eventually a webapp based on a browser 
built-in API, or a plugin, to create a suitable interface for queries) 
to extract and merge informations.

>>>> What is the cost of having different data use specialised formats?
>>>
>>> If the data model, or a part of it, is not explicit as in RDF but is 
>>> implicit in code made to treat it (as is the case with using scripts 
>>> to process things stored in arbitrarily named data-* attributes, and 
>>> is also the case in using undocumented or semi-documented XML 
>>> formats, it requires people to understand the code as well as the 
>>> data model in order to use the data. In a corporate situation where 
>>> hundreds or tens of thousands of people are required to work with 
>>> the same data, this makes the data model very fragile.
>>>
>>
>> I'm not sure RDF(a) solves such a problem. AIUI, RDFa just binds 
>> (xml) properties and attributes (in the form of curies) to RDF 
>> concepts, modelling a certain kind of relationships, whereas it 
>> relies on external schemata to define such properties. Any 
>> undocumented or semi-documented XML formats may lead to misuses and, 
>> thus, to unreliably modelled data,
> ...
>
>> I think the same applies to data-* attributes, because _they_ 
>> describe data (and data semantics) in a custom model and thus _they_ 
>> need to be documented for others to be able to manipulate them; the 
>> use of a custom script rather than a built-in parser does not change 
>> much from this point of view.
>
> RDFa binds data to RDF. RDF provides a well-known schema language with 
> machine-processable definition of vocabularies, and how to merge 
> information between them. In other words, if you get the underlying 
> model for your data right enough, people will be able to use it 
> without needing to know what you do.
>
> Naturally not everyone will get their data model right, and naturally 
> not all information will be reliable anyway. However, it would seem to 
> me that making it harder to merge the data in the first place does not 
> assist in determining whether it is useful. On the other hand, certain 
> forms of RDF data such as POWDER, FOAF, Dublin Core and the like have 
> been very carefully modelled, and are relatively well-known and 
> re-used in other data models. Making it easy to parse this data and 
> merge it, according to the existing well-developed models seems valuable.
>

I admit I'm not very expert in RDF use, thus I have a few questions. 
Specifically, maybe I can guess the advantages when using the same 
(carefully modelled, and well-known) vocabulary/ies; but when two 
organizations develop their own vocabularies, similar yet different, to 
model the same kind of informations, is merging of data enough? Can a 
processor give more than a collection of triples, to be then interpreted 
basing on knowledge on the used vocabulary/ies?

I mean, I assume my tools can extract RDF(a) data from whatever 
document, but my query interface is based on my own vocabulary: when I 
merge informations from an external vocabulary, do I need to translate 
one vocabulary to the other (or at least to modify the query backend, so 
that certain curies are recognized as representing the same concepts - 
e.g. to tell my software that 'foaf:name' and 'ex:someone' are 
equivalent, for my purposes)? If so, merging data might be the minor 
part of the work I need to do, with respect to non-RDF(a) metadata (that 
is, I'd have tools to extract and merge data anyway, and once I 
translated external metadata to my format, I could use my own tools to 
merge data), specially if the same model is used both by mine and an 
external organization (therefore requiring an easier translation).

Thus, I'm thinking the most valuable benefit of using RDF/RDFa is the 
sureness that both parties are using the very same data model, despite 
the possible use of different vocabularies -- it seems to me that the 
concept of triples consisting of a subject, a predicate and an object is 
somehow similar to a many-to-many association in a database, whereas one 
might prefer a one-to-many approach - though, the former might be a 
natural choice to model data which are usually sparse, as in a document 
prose.

>
>>> Ian wrote:
>>>> For search engines, I am not convinced. Google's experience is that
>>>> natural language processing of the actual information seen by the 
>>>> actual end user is far, far more reliable than any source of metadata.
>>>> Thus from Google's perspective, investing in RDFa seems like a poorer
>>>> investment than investing in natural language processing.
>>>
>>> Indeed. But Google is something of an edge case, since they can 
>>> afford to run a huge organisation with massive computer power and 
>>> many engineers to address a problem where a "near-enough" solution 
>>> brings themn the users who are in turn the product they sell to 
>>> advertisers. There are many other use cases where a small group of 
>>> people want a way to reliably search trusted data.
>>>
>>
>> I think the point with general purpose search engines is another one: 
>> natural language processing, whereas being expensive, grants a far 
>> more accurate solution than RDFa and/or any other kind of metadata 
>> can bring to a problem requiring data must never need to be trusted 
>> (and, instead, a data processor must be able to determine data's 
>> level of trust without any external aid).
>
> No, I don't think so. Google searches based on analysis of the open 
> web are *not* generally more reliable than faceted searches over a 
> reliable dataset, and in some instances are less reliable.
>
> The point is that only a few people can afford to invest in being a 
> general-purpose search engine, whereas many can afford to run a 
> metadata-based search system over a chosen dataset, that responds to 
> their needs (and doesn't require either publishing their data, or 
> paying Google to index it).
>

My point is that possible assumptions over datasets reliability is the 
borderline between wide-scale data extraction/classification, which is 
the main problem solved by a general purpose search engine, and implies 
the best assumption by default is datasets reliability is uncertain, and 
(very) small-scale data modelling, were a direct and immediate 
evaluation over datasets reliability is possible and easy to do, so that 
a custom search engine could reliably be based on such metadata. I think 
no comparison is possible between the two scales, thus no generalization 
is possible when trying to guess whether metadata can do more good than 
harm, but instead each case should be analysed separately, and everyone 
should agree which one is the best context (eventually both) where RDFa 
should be used, to understand what's the best way to implement it and if 
it's worth to be introduced in html5 -- as far as I can tell, both of us 
agree that small-scale is the main context.

But perhaps some edge-side case should be considered to draw a better 
picture. For instance, one such case might be a browser availing of 
metadata to search a resource in its local history, or within a web page 
and related/linked pages (to a certain digree and level of depth), 
because its scale would be small with respect to the effective number of 
scanned resources, but wide with respect to the potential number of 
sources for those resources, that is, because a browser implementing a 
metadata extraction and merging engine and a query interface to look for 
gleaned informations would deal with a | limited number | of | 
etherogeneous sources | at a given time.

Once major browsers provided (and exposed by default) such a 
functionality, a growing number of users would (try and) use it, thus a 
growing number of sites would experiment metadata. At the beginning 
everything might work fine, since only honest sites would experiment 
honest metadata (such as wikis, for instance), but once the number of 
sites and users availing of metadata reached a threshold point spammers 
would start including spam metadata in their sites (with otherwise 
trustful content) and in other sites through advertisements. Such a 
scenario might lead to a bad balance between benefits and disadvantages 
for the average user, thus pushing (some) browser vendors to limit or 
even to wholly drop native support, and I guess this is not a wishable 
solution for the Semantic Web Industry.

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 plugins, or scripts to be 
embedded in a webbapp, and working on top of other feature might work 
fine and lead to a better, native support by all vendors, yet limited to 
an API for custom applications -- whereas any changes to html to include 
RDFa attributes would be fully meaningful if leading to a full support 
and exposed features to avail of metadata, which I don't think is much 
of a benefit for the great majority of (home) users.

Everything, IMHO

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Meetic: il leader italiano ed europeo per trovare l'anima gemella online. Provalo ora
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8291&d=9-1


From alex.baldacchino at email.it  Thu Jan  8 19:01:34 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 09 Jan 2009 04:01:34 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <op.um9bugnzwxe0ny@widsithpro.lan>
References: <A830F423-8769-4EAD-8646-ED4FD63E09DD@tobyinkster.co.uk>	<7441982A-967C-4D67-86D9-B70D9EA40FE7@iki.fi>	<495E021E.8010407@googlemail.com>	<C3014DFF-C5FD-40A2-B479-072893BD60D7@iki.fi>
	<op.um9bugnzwxe0ny@widsithpro.lan>
Message-ID: <4966BE0E.3070802@email.it>

Charles McCathieNevile ha scritto:
> On Mon, 05 Jan 2009 01:21:33 +1100, Henri Sivonen <hsivonen at iki.fi> 
> wrote:
>> On Jan 2, 2009, at 14:01, Benjamin Hawkes-Lewis wrote:
>>> On 2/1/09 10:38, Henri Sivonen wrote:
>
>>>> Is the problem in the case of recipes that the provider of the page
>>>> navigation around the recipe is unwilling to license the navigation 
>>>> bits under the same license as the content proper?
>>>
>>> I thought Toby's example was that each recipe on the page needed a 
>>> different licence, rather than a distinction between the main 
>>> content area and the navigation.
>>
>> Oh. That can be solved by giving each recipe its own URI & HTML page 
>> and scraping those pages instead of summary pages that might contain 
>> multiple recipes.
>
> Sure. In which case the problem becomes "doing mashups where data 
> needs to have different metadata associated is impossible", so the 
> requirement is "enable mashups to carry different metadata about bits 
> of the content that are from different sources.
>
> A use case for this:
>
> There are mapping organisations and data producers and people who take 
> photos, and each may place different policies. Being able to keep that 
> policy information helps people with further mashups avoiding 
> violating a policy.
>
> For example, if GreatMaps.com has a public domain policy on their 
> maps, CoolFotos.org has a policy that you can use data other than 
> images for non-commercial purposes, and Johan Ichikawa has a photo 
> there of my brother's caf?, which he has licensed as "must pay money", 
> then it would be reasonable for me to copy the map and put it in a 
> brochure for the caf?, but not to copy the data and photo from 
> CoolFotos. On the other hand, if I am producing a non-commercial guide 
> to caf?s in Melbourne, I can add the map and the location of the cafe 
> photo, but not the photo itself.
>

It seems a scenario where a human should carefully evaluate each licence 
and perhaps put a careful and human readable prose into the mashed-up 
page, or a link to such a prose. Metadata may or may not be accurate 
(e.g. may be misplaced and not contain the whole license, or refer to a 
wrong kind of license, different from the one stated in the prose), but 
the whole prose (and perhaps only that) is legally binding for sure (I'm 
not aware of any international law recognizing metadata and/or 
machine-processable/machine-friendly extracted content as a valid legal 
agreement/notice - in your example, Johan Ichikawa might put the "must 
pay money" license in a span containing a metadata reference to a 
creative commons license, but only the "must pay money" license is 
surely valid as a legal notice, as far as I can tell).


> Another use case:
> My wife wants to publish her papers online. She includes an abstract 
> of each one in a page, but because they are under different copyright 
> rules, she needs to clarify what the rules are. A harvester such as 
> the Open Access project can actually collect and index some of them 
> with no problem, but may not be allowed to index others. Meanwhile, a 
> human finds it more useful to see the abstracts on a page than have to 
> guess from a bunch of titles whether to look at each abstract.
>
>

I'm not strongly for one solution or the other in this case (an actual 
choice may depend on several considerations, such as harvesters 
reputation, or the need to use metadata anyway for private purposes), 
but this case might be addressed by embedding each abstract in an 
iframe, so that human users would get all of them in a single page, 
while a harvester would need to navigate each page to index/copy it, and 
a proper metadata might be put into each page, or each page might have a 
different rule to restrict access (e.g. through a robot file, or the 
Access-Control semantics, or any kind of white- or black- lists), 
specially to prevent a malicious harvester (that is one deliberately 
ignoring metadata and licenses) from accessing certain contents.

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Email.it offre alle aziende il servizio di Email Marketing con pacchetti di invio a 10.000 utenti a soli 250 Euro
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8352&d=9-1


From julian.reschke at gmx.de  Fri Jan  9 03:46:46 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 09 Jan 2009 12:46:46 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4966AE40.3040600@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
Message-ID: <49673926.4020902@gmx.de>

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 dataset would give 
> access to "rdfa-about", instead of just "about", that is using the 
> prefix "rdfa-" as acting as a namespace prefix in xml (hence, as if 
> there were "rdfa:about" instead of "data-rdfa-about" in the markup).
> ...

That clashed with the documented purpose of data-*.

*If* we want to support RDFa, why not add the attributes the way they 
are already named???

> ...
> However, AIUI, actual xml serialization (xhtml5) allows the use of 
> namespaces and prefixed attributes, thus couldn't a proper namespace be 
> introduced for RDFa attributes, so they can be used, if needed, in 
> xhtml5 documents? I think such might be a valuable choice, because it 
> seems to me RDFa attributes can be used to address such cases where 
> metadata must stay as close as possible to correspondent data, but a 
> mistake in a piece of markup may trigger the adoption agency or foster 
> parenting algorithms, eventually causing a separation between metadata 
> and content, thus possibly breaking reliability of gathered 
> informations. From this perspective, a parser stopping on the very first 
> error might give a quicker feedback than one rearranging misnested 
> elements as far as it is reasonably possible (not affecting, and instead 
> improving, content presentation and users' "direct" experience, but 
> possibly causing side-effects with metadata).
> ...

That would make RDFa as used in XHTML 1.* and RDFa used in HTML 5 
incompatible. What for?

 > ...

BR, Julian


From msporny at digitalbazaar.com  Fri Jan  9 06:56:01 2009
From: msporny at digitalbazaar.com (Manu Sporny)
Date: Fri, 09 Jan 2009 09:56:01 -0500
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor) (was:
 Trying to work out the problems solved by RDFa)
In-Reply-To: <4966AE40.3040600@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
Message-ID: <49676581.9060301@digitalbazaar.com>

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 plugins, or scripts to be
> embedded in a webbapp, and working on top of other feature might work
> fine and lead to a better, native support by all vendors, yet limited to
> an API for custom applications

There seems to be a bit of confusion over what RDFa can and can't do as
well as the current state of the art. We have created an RDFa Firefox
plugin called Fuzzbot (for Windows, Linux and Mac OS X) that is a very
rough demonstration of how an browser-based RDFa processor might
operate. If you're new to RDFa, you can use it to edit and debug RDFa
pages in order to get a better sense of how RDFa works.

There is a primer[1] to the semantic web and an RDFa basics[2] tutorial
on YouTube for the completely un-initiated. The rdfa.info wiki[3] has
further information.

----------------
(sent to public-rdfa at w3.org earlier this week):

We've just released a new version of Fuzzbot[4], this time with packages
for all major platforms, which we're going to be using at the upcoming
RDFa workshop at the Web Directions North 2009 conference[5].

Fuzzbot uses librdfa as the RDFa processing back-end and can display
triples extracted from webpages via the Firefox UI. It is currently most
useful when debugging RDFa web page triples. We use it to ensure that
the RDFa web pages that we are editing are generating the expected
triples - it is part of our suite of Firefox web development plug-ins.

There are three versions of the Firefox XPI:

Windows XP/Vista (i386)
http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-windows.xpi

Mac OS X (i386)
http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-macosx-i386.xpi

Linux (i386) - you must have xulrunner-1.9 installed
http://rdfa.digitalbazaar.com/fuzzbot/download/fuzzbot-linux.xpi

There is also very preliminary support for the Audio RDF and Video RDF
vocabularies, demos of which can be found on YouTube[6][7].

To try it out on the Audio RDF vocab, install the plugin, then click on
the Fuzzbot icon at the bottom of the Firefox window (in the status bar):

http://bitmunk.com/media/6566872

There should be a number of triples that show up in the frame at the
bottom of the screen as well as a music note icon that shows up in the
Firefox 3 AwesomeBar.

To try out the Video RDF vocab, do the same at this URL:

http://rdfa.digitalbazaar.com/fuzzbot/demo/video.html

Please report any installation or run-time issues (such as the plug-in
not working on your platform) to me, or on the librdfa bugs page:

http://rdfa.digitalbazaar.com/librdfa/trac

-- manu

[1] http://www.youtube.com/watch?v=OGg8A2zfWKg
[2] http://www.youtube.com/watch?v=ldl0m-5zLz4
[3] http://rdfa.info/wiki
[4] http://rdfa.digitalbazaar.com/fuzzbot/
[5] http://north.webdirections.org/
[6] http://www.youtube.com/watch?v=oPWNgZ4peuI
[7] http://www.youtube.com/watch?v=PVGD9HQloDI

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.

blog: Fibers are the Future: Scaling Past 100K Concurrent Requests
http://blog.digitalbazaar.com/2008/10/21/scaling-webservices-part-2


From bzbarsky at MIT.EDU  Fri Jan  9 10:42:47 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 09 Jan 2009 13:42:47 -0500
Subject: [whatwg] Origins, reprise
Message-ID: <49679AA7.2020902@mit.edu>

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, port).

(with some steps to determine the tuple thrown in).

In Gecko, we actually have three classes of URIs for security purposes:

1) Those for which the URI is not same-origin with anything (the
    globally unique identifier case).
2) Those for which the URI is same-origin with anything with the same
    scheme+host+port.
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).

It would be nice if we could express this in terms of the origin setup, 
but it doesn't seem to me like that's workable as things stand...

-Boris


From jackalmage at gmail.com  Fri Jan  9 11:35:10 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 9 Jan 2009 13:35:10 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <49673926.4020902@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
	<49673926.4020902@gmx.de>
Message-ID: <dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>

On Fri, Jan 9, 2009 at 5:46 AM, Julian Reschke <julian.reschke at gmx.de> 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 (perhaps in a test
>> phase, if needed at all, of course), an element dataset would give access to
>> "rdfa-about", instead of just "about", that is using the prefix "rdfa-" as
>> acting as a namespace prefix in xml (hence, as if there were "rdfa:about"
>> instead of "data-rdfa-about" in the markup).
>> ...
>
> That clashed with the documented purpose of data-*.
>
> *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 whether there's a problem
we need to solve, or how we should solve it.

Alex's suggestion, while officially against spec, has the benefit of
allowing RDFa supporters to sort out their use cases through
experience.  That's the back door into the spec, after all; you don't
have to do as much work to formulate a problem statement if you can
point to large amounts of people hacking around a current lack, as
that's a pretty strong indicator that there *is* a problem needing to
be solved.  As an added benefit, the fact that there's already
multiple independent attempts at a solution gives us a wide pool of
experience to draw from in formulating the actual spec, so as to make
the use as easy as possible for authors.

(An example that comes to mind in this regard is rounded corners.
Usually you have to break semantics and put in junk elements to get
rounded corners on a flexible box.  This became so common that the
question of whether or not rounded corners were significant enough to
be added in CSS answered itself - people are trying hard to hack the
support in, so it's clearly something they want, and thus it's
worthwhile to spec a method (the border-radius property) to give them
it.  It solves a problem that authors, through their actions, made
extremely clear, and it does so in a way that is enormously simpler
99% of the time.  Win-win.)

~Tj


From julian.reschke at gmx.de  Fri Jan  9 11:41:10 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Fri, 09 Jan 2009 20:41:10 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	
	<48B5D840.5000704@digitalbazaar.com>	
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>	
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>	
	<49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
Message-ID: <4967A856.5010206@gmx.de>

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 whether there's a problem
> we need to solve, or how we should solve it.

For the record: I disagree with that. I have the impression that no 
matter how many problems are presented, the answer is going to be: "not 
that stone -- fetch me another stone".

> Alex's suggestion, while officially against spec, has the benefit of
> allowing RDFa supporters to sort out their use cases through
> experience.  That's the back door into the spec, after all; you don't

If something that is against the spec is acceptable, then it's *much* 
easier to just use the already defined attributes. Better breaking the 
spec by using new attributes then abusing existing ones.

 > ...

BR, Julian


From ben at adida.net  Fri Jan  9 11:48:36 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 11:48:36 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967A856.5010206@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>		<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>		<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>		<48B5D840.5000704@digitalbazaar.com>		<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>		<op.um19y5ajwxe0ny@widsithpro.lan>
	<495F97A9.1080602@email.it>		<op.um7lz7ufwxe0ny@widsithpro.lan>
	<4966AE40.3040600@email.it>		<49673926.4020902@gmx.de>	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de>
Message-ID: <4967AA14.2000503@adida.net>

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 record: I disagree with that. I have the impression that no
> matter how many problems are presented, the answer is going to be: "not
> that stone -- fetch me another stone".

For the record: I completely agree with Julian. This is why I haven't
jumped into this thread yet again.

The key piece of evidence here is SearchMonkey, a product by Yahoo that
specifically uses RDFa. Even its microformat support funnels everything
to an RDF-like metadata approach. With thousands of application
developers and some concrete examples that specifically use RDFa (the
Creative Commons application being one of them), the message from many
on this list remains "not good enough."

I'm not sure where the bar is, but it seems far from objective.

-Ben


From alex.baldacchino at email.it  Fri Jan  9 12:07:47 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 09 Jan 2009 21:07:47 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <49673926.4020902@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
	<49673926.4020902@gmx.de>
Message-ID: <4967AE93.9040201@email.it>

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 all, of course), an element dataset would 
>> give access to "rdfa-about", instead of just "about", that is using 
>> the prefix "rdfa-" as acting as a namespace prefix in xml (hence, as 
>> if there were "rdfa:about" instead of "data-rdfa-about" in the markup).
>> ...
>
> That clashed with the documented purpose of data-*.

Hmm, I'm not sure there is a clash, since I was suggesting a *custom* 
and essentially *private* mechanism to experiment with RDFa in 
conjunction with HTML serialization, for the *small-scale* needs of some 
organizations willing to embed RDFa metadata in text/html documents, and 
to exchange them with each other by using a convention likely avoiding 
name clashes with other private metadata. Since I think it's unlikely to 
find data-rdfa-* used with different semantics in the very same page, 
and in a small-scale scenario involving a few *selected* sources for 
RDFa-modelled information, it should be likely to know in advance that 
someone else is using the same conventions. Such a modelled document 
might be used in conjunction with an external RDFa processor, thus 
avoiding any direct support in a browser.

However, such a convention might be enough "clash-free" to work on a 
wider scale, thus it might become widespread and provide an evidence 
that the web /needs/, or at least /has chosen/ to use RDFa as (one of) 
the most common way to embed metadata in a document, and such might be 
enough to add a native support for the whole range of "RDFa" attributes, 
eventually along with support for earlier experimental ones (such as 
"data-rdfa-*" and "rdfa:*" ones, for backward compatibility). And 
actually I can't see much of a problem if a private-born feature became 
the base of a widespread and widely accepted convention (I'm not saying 
the spec should name data-rdfa-* as a mean to implement RDFa, instead I 
think that, if a general agreement on if and how RDFa must be spec'ed 
out and implemented can't be found, such an experiment might be proposed 
to the semantic web industry and wait for the results - given a lack in 
support might prevent any interested party to use RDFa and HTML5 
altogether).

>
> *If* we want to support RDFa, why not add the attributes the way they 
> are already named???
>

For instance, to experiment whether it is worth to change the "if we 
want" into "we do want", without requiring an early implementation and 
specification, nor relying on if and what a certain browser vendor might 
want to experiment differently from others (such a convention would only 
require support for HTML5 datasets and a script or a plugin capable to 
handle them as representing RDFa metadata). -- the point here is that 
after introducing data-* attributes as a mean to support custom 
attributes any browser vendors might decide to drop support for other 
kind of custom attributes in html serialization (that is, for attributes 
being neither part of the language nor data-* ones), therefore if they 
(or any of them) decided to avoid to support RDFa attributes until they 
were introduced in a specification there might be no mean to experiment 
with them (in general, that is cross-browser) without resorting either 
to data-* or to "rdfa:*" (the latter in xhtml).

Anyway, /in general/ what should a browser do with RDFa metadata, on a 
*wide scale*, other than classifying a portion of the open web (e.g. in 
its local history), eventually allowing users to select trusted sources?

Actually, I don't think such would bring enough benefits for *average* 
users, compared to the risk to get a lot of spam metadata from 
/heterogeneous/ sources. I really don't expect average users to 
understand how to filter sites basing on metadata reliability (and just 
for the purpose to use a metadata-based query interface, because a site 
with wrong metadata might still contain usefull informations); instead 
they might just try and use a query interface the same way they use a 
default search bar, get wrong results (once spam metadata became 
widespread) and decide the mechanism doesn't work fine (eventually 
complaining for that). A somewhat antispam filter might help, but I 
think that understanding if metadata are reliable, that is if they 
really correspond to a web page content, is an odd problem to be solved 
by a bot without a good degree of Artificial Intelligence (filtering 
emails by looking for suspicious patterns is far easier than 
implementing a filter capable to /understand/ metadata, /understand/ 
natural language and compare /semantics/ ).

As well, I don't expect the great majority of web pages to contain 
"valid" metadata: most people would not care of them, and a potentially 
growing number might copy&paste code containing metadata from other 
sites as a kind of template, then edit the content and ignore any 
metadata, thus breaking reliability. I do think wide-scale use of 
metadata coming from heterogeneous sources can be more harmful than 
useful. *If* we do agree that small-scale needs is the main context 
where RDFa can bring benefits, perhaps a custom mechanism and external 
plugins are all we need; otherwise, it should be proved that /misused/ 
and /abused/ metadata can be filtered out *easily* and *automatically*, 
without requiring average users to understand the problem, nor affecting 
the overall efficiency. IMHO.

>> ...
>> However, AIUI, actual xml serialization (xhtml5) allows the use of 
>> namespaces and prefixed attributes, thus couldn't a proper namespace 
>> be introduced for RDFa attributes, so they can be used, if needed, in 
>> xhtml5 documents? I think such might be a valuable choice, because it 
>> seems to me RDFa attributes can be used to address such cases where 
>> metadata must stay as close as possible to correspondent data, but a 
>> mistake in a piece of markup may trigger the adoption agency or 
>> foster parenting algorithms, eventually causing a separation between 
>> metadata and content, thus possibly breaking reliability of gathered 
>> informations. From this perspective, a parser stopping on the very 
>> first error might give a quicker feedback than one rearranging 
>> misnested elements as far as it is reasonably possible (not 
>> affecting, and instead improving, content presentation and users' 
>> "direct" experience, but possibly causing side-effects with metadata).
>> ...
>
> That would make RDFa as used in XHTML 1.* and RDFa used in HTML 5 
> incompatible. What for?
>
> > ...
>
> BR, Julian

Because I'm not sure RDFa can work fine with HTML serialization. To 
clarify that, let me take and modify an example from W3C Recommendation 
(without pretending it to be a good example to build a good worst-case 
scenario, but just to give an idea):

[...]
<p>
   I'm holding
   <span property="cal:summary">
     one last summer Barbecue
   </span>, to meet friends and have a party before the end of holidays
   on
   <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
         datatype="xsd:dateTime">
     September 16th at 4pm
   </span>.
</p>
[...]


Now let consider it written as:

[...]
<p>
  I'm holding
  <span property="cal:summary">
    one last summer Barbecue
 <!-- now the </span> close tag is missing here -->,
  to meet friends and have a party before the end of holidays
  on
  <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
        datatype="xsd:dateTime">
    September 16th at 4pm
  </span>.
</p>
[...]


The above would result in a parse error as an xml-serialized document, 
since the document isn't well formed. Instead, as part of an 
html-serialized document, the above fragment would be processed anyway, 
improving users' experience (with respect to a page stopping rendering 
on a missing close tag), but potentially causing metadata to be 
imprecisely binded to any data, thus potentially harming automated data 
extraction (for some purpose). Therefore, perhaps using such metadata 
only inside xml serialized pages might give a quick feedback on such a 
problem as soon as the author checked a page appearance (which I think 
would be the very first check, as well as I think about no one would 
check the _whole_ range of possible queries people might make over a 
document, to look for errors).

*If* this is meaningful, supporting RDFa attributes as "rdfa:*" might 
ensure that xml serialization is preferred by people really needing to 
use this kind of metadata (while leaving a chance to experiment RDFa 
with html serialization, because no one can be prohibited to use 
data-<prefix>-* for this purpose beside a proper script or plugin), 
whereas introducing "about", "property", "content", "datatype" and so on 
directly in html namespace, as attributes shared by all elements, would 
make the choice of one serialization or the other indifferent, thus 
leading to every possible side-effects html serialization may cause.

As a side note, It seems that people from the W3C are evaluating a 
resort to extensibility to introduce RDFa attributes into xml-serialized 
html documents, and they also have some doubts whether allow use of RDFa 
attributes within html serialization or not:

"The HTML WG is encouraged to provide a mechanism to permit 
independently developed vocabularies such as Internationalization Tag 
Set (ITS), Ruby, and RDFa to be mixed into HTML documents. /Whether this 
occurs through the extensibility mechanism of XML, *whether it is also 
allowed in the classic HTML serialization*, and whether it uses the DTD 
and Schema modularization techniques/, is for the HTML WG to determine."
(from <http://www.w3.org/2007/03/HTML-WG-charter#deliverables>)

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Meetic: il leader italiano ed europeo per trovare l'anima gemella online. Provalo ora
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8291&d=9-1


From jackalmage at gmail.com  Fri Jan  9 12:14:18 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 9 Jan 2009 14:14:18 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967AA14.2000503@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
	<49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
Message-ID: <dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>

On Fri, Jan 9, 2009 at 1:48 PM, Ben Adida <ben at adida.net> 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 need to solve, or how we should solve it.
>>
>> For the record: I disagree with that. I have the impression that no
>> matter how many problems are presented, the answer is going to be: "not
>> that stone -- fetch me another stone".
>
> For the record: I completely agree with Julian. This is why I haven't
> jumped into this thread yet again.
>
> The key piece of evidence here is SearchMonkey, a product by Yahoo that
> specifically uses RDFa. Even its microformat support funnels everything
> to an RDF-like metadata approach. With thousands of application
> developers and some concrete examples that specifically use RDFa (the
> Creative Commons application being one of them), the message from many
> on this list remains "not good enough."
>
> I'm not sure where the bar is, but it seems far from objective.

Actually, SearchMonkey is an excellent use case, and provides a
problem statement.

Problem
=======

Site owners want a way to provide enhanced search results to the
engines, so that an entry in the search results page is more than just
a bare link and snippet of text, and provides additional resources for
users straight on the search page without them having to click into
the page and discover those resources themselves.

For example (taken directly from the SearchMonkey docs), yelp.com may
want to provide additional information on restaurants they have
reviews for, pushing info on price, rating, and phone number directly
into the search results, along with links straight to their reviews or
photos of the restaurant.

Different sites will have vastly different needs and requirements in
this regard, preventing natural discovery by crawlers from being
effective.

(SearchMonkey itself relies on the user registering an add-in on their
Yahoo account, so spammers can't exploit this - the user has to
proactively decide they want additional information from a site to
show up in their results, then they click a link and the rest is
automagical.)


That really wasn't hard.  I'd never seen SearchMonkey before (it's
possible it was mentioned, but I know that it was never explicitly
described), but it's a really sweet app that helps both authors and
users.  That's a check mark in my book.

~TJ


From ben at adida.net  Fri Jan  9 12:17:28 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 12:17:28 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>	
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>	
	<49673926.4020902@gmx.de>	
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
Message-ID: <4967B0D8.6020103@adida.net>

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 good use
case.

-Ben



From jackalmage at gmail.com  Fri Jan  9 13:00:11 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 9 Jan 2009 15:00:11 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967B0D8.6020103@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<495F97A9.1080602@email.it> <op.um7lz7ufwxe0ny@widsithpro.lan>
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>
Message-ID: <dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>

On Fri, Jan 9, 2009 at 2:17 PM, Ben Adida <ben at adida.net> 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
> in his email a few days ago, then proceeded to say it wasn't a good use
> case.

I apologize; looking back into my archives, it appears there was an
entire subthread specifically about SearchMonkey!  Also, Ian did
indeed mention it in his first email in this thread.  He actually gave
it more attention than any other single use-case, though.  I'll quote
the relevant part:

> On Tue, 26 Aug 2008, Ben Adida wrote:
> >
> > Here's one example. This is not the only way that RDFa can be helpful,
> > but it should help make things more concrete:
> >
> >   http://developer.yahoo.com/searchmonkey/
> >
> > Using semantic markup in HTML (microformats and, soon, RDFa), you, as a
> > publisher, can choose to surface more relevant information straight into
> > Yahoo search results.
>
> This doesn't seem to require RDFa or any generic data syntax at all. Since
> the system is site-specific anyway (you have to list the URLs you wish to
> act against), the same kind of mechanism could be done by just extracting
> the data straight out of the page. This would have the advantage of
> working with any Web page without requiring the page to be written using a
> particular syntax.
>
> However, if SearchMonkey is an example of a use case, then we should
> determine the requirements for this feature. It seems, based on reading
> the documentation, that it basically boils down to:
>
>  * Pages should be able to expose nested lists of name-value pairs on a
>   page-by-page basis.
>
>  * It should be possible to define globally-unique names, but the syntax
>   should be optimised for a set of predefined vocabularies.
>
>  * Adding this data to a page should be easy.
>
>  * The syntax for adding this data should encourage the data to remain
>   accurate when the page is changed.
>
>  * The syntax should be resilient to intentional copy-and-paste authoring:
>   people copying data into the page from a page that already has data
>   should not have to know about any declarations far from the data.
>
>  * The syntax should be resilient to unintentional copy-and-paste
>   authoring: people copying markup from the page who do not know about
>   these features should not inadvertently mark up their page with
>   inapplicable data.
>
> Are there any other requirements that we can derive from SearchMonkey?

I agree with Ian in that SearchMonkey is not *necessarily* speaking in
favor of RDFa; that may be what caused you to think he was dismissing
it.  In truth, Ian is merely trying to take current examples of RDFa
use and distill them into their essence.  (To grab my previous
example, it is similar to seeing what all the various rounded-corners
hacks were doing, without necessarily implying that the final solution
will be anything like them.  It's important to distill the actual
problems that users are solving from the details of particular
solutions they are using.)

Like I said, I think SearchMonkey sounds absolutely awesome, and
genuinely useful on a level I haven't yet seen any apps of similar
nature reach.  I'm exclusively a Google user, but that's something I'd
love to have ported over.  It's similar in nature to IE8's
Accelerators, in that it's an opt-in application for users that
reduces clicks to get to information they actively decide they want.

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.  It is likely that this can be done entirely
within the confines of current html, and the fact that SearchMonkey
can use Microformats suggests that this is true.  A possible approach
is a site-owner producing an ad-hoc microformat (little m) that the
crawler can match against pages and index the information of, and then
offer to the SearchMonkey application for presentation as the
developer wills.  This would require specified parsing rules for such
things (which, as mentioned in an earlier email, the big-m
Microformats community is working on).

The question is, would this be sufficient?  Are other approaches
easier for authors?  RDFa, as noted, already has a specified parsing
model.  Does this make it easier for authors to design data templates?
 Easier to communicate templates to a crawler?  Easier to deploy in a
site?  Easier to parse for a crawler?

SearchMonkey makes mention of developers producing SearchMonkey apps
without the explicit permission of site owners.  This use would almost
certainly be better served with a looser data discovery model than
RDFa, so that a site owner doesn't have to explicitly comply in order
for others to extract useful data from their pages.  How important is
this?


These are precisely the sort of questions I think Ian wants and needs
asked.  SearchMonkey is an awesome app; do we need to do anything to
support it and similar apps?  *Can* anything we do support it, or is
it best served by solutions that ignore us completely?  Yes,
SearchMonkey operates on metadata, and the problem space doesn't allow
natural-language processing to stand in for it; it is not clear,
though, that a strict markup approach is best for authors or users.
Nevertheless, it is an excellent use-case to distill requirements from
so we *can* determine if a spec-based solution is desirable.

~TJ


From whatwg at adambarth.com  Fri Jan  9 13:16:57 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Fri, 9 Jan 2009 13:16:57 -0800
Subject: [whatwg] Origins, reprise
In-Reply-To: <49679AA7.2020902@mit.edu>
References: <49679AA7.2020902@mit.edu>
Message-ID: <7789133a0901091316g58f02b51m57f3e4697fae8799@mail.gmail.com>

On Fri, Jan 9, 2009 at 10:42 AM, Boris Zbarsky <bzbarsky at mit.edu> 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


From ben at adida.net  Fri Jan  9 13:22:04 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 13:22:04 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<495F97A9.1080602@email.it> <op.um7lz7ufwxe0ny@widsithpro.lan>	
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>	
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>	
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>	
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
Message-ID: <4967BFFC.4080305@adida.net>

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 SearchMonkey infobar that is set to function on all URLs
(just use "*" in your URL field.)

For example, the Creative Commons SearchMonkey application:

http://gallery.search.yahoo.com/application?smid=kVf.s

(currently broken because of a recent change in the SearchMonkey PHP API
that we need to address, so here's a photo:

http://www.flickr.com/photos/ysearchblog/2869419185/
)

By adding the CC RDFa markup to your page, it will show up with the
infobar in Yahoo searches.

So site-specific microformats are clearly less powerful. And
vocabulary-specific microformats, while useful, are also not as useful
here (consider a SearchMonkey application that picks up CC-licensed
items, be they video, audio, books, scientific data, etc... Different
microformats = development hell.)

Have you read the RDFa Primer?
http://www.w3.org/TR/xhtml-rdfa-primer/

It describes (pre-SearchMonkey) the kind of applications that can be
built with RDFa. SearchMonkey is an ideal example, but it's by no means
the only one.

-Ben


From alex.baldacchino at email.it  Fri Jan  9 13:56:21 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Fri, 09 Jan 2009 22:56:21 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967B0D8.6020103@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>	
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>	
	<49673926.4020902@gmx.de>	
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>
Message-ID: <4967C805.70908@email.it>

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 proceeded to say it wasn't a good use
> case.
>
> -Ben
>
>   

It seems to me that's a very custom use case - though requiring metadata 
to be embedded in a big number of pages, but that's an optional 
requirement, because search results don't rely only on metadata -  since 
metadata are used as an optional source for informations by the server 
and don't require any collaboration by other kinds of UA (excluding, at 
most, some custom data services - whereas, for instance, a search engine 
using the mark element to highlight a keyword would require a client UA 
to understand and style it properly -- I expect it not to be working on 
IE6, for instance, because IEx browsers deal with unknown elements as if 
their content where misplaced). That is, Yahoo might develop his own 
data model and work fine with sites implementing it; perhaps RDF(a) was 
chosen because they might think RDF is a natural way to model data which 
are sparse in a web page (and re-mapping microformats on RDF might 
result in an easier implementation); anyway, in this case the only UA 
needing to understand RDFa, in this case, is SearchMonkey itself, thus a 
client browser might just drop RDFa attributes without breaking 
SearchMonkey functionalities -- at least, this is my first impression.

Furthermore, it's a very recent (yet potentially interesting) 
application, so why not to wait and see how it grows, if the opt-in 
mechanism will effectively prevent spam (e.g. spammers might model data 
basing on widely diffused vocabularies and data services, and find a way 
to make such data available in searches when users asks for additional 
infos, for instance through an ad within a page of an accomplice author, 
or exploiting some kind of errors in authors' selection of URLs to be 
crawled for metadata, or the alike), or just which model become the most 
used among RDFa, eRDF, Microformats, Atom embedding dataRSS and whatever 
else Yahoo might decide to support, before choosing to include one or 
the other into html5 specification (or to include each one because 
equally diffused)? Moreover, it seems that some xml processing is needed 
to create a custom data service, thus it might be natural to use xhtml 
(possibly along with namespaces and prefixed attributes) to provide 
metadata to such a data service, which might rely on an xml parser 
instead of implementing one from scratch (and html parser might not 
support namespaces for the purpose to expose them through DOM 
interfaces, as I understand html serialization) -- the use of prefixed 
RDFa attributes, or perhaps even unprefixed ones, within an 
xml-serialized document, shouldn't require a formalization in html5 
spec, as far as there is no strict requirement for UAs to support RDF 
processing - as it is for the purposes of SearchMonkey and its related 
data services.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8551&d=9-1


From jackalmage at gmail.com  Fri Jan  9 14:13:43 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 9 Jan 2009 16:13:43 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967BFFC.4080305@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
	<4967BFFC.4080305@adida.net>
Message-ID: <dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>

On Fri, Jan 9, 2009 at 3:22 PM, Ben Adida <ben at adida.net> 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 how to present it.
>
> That's incorrect.
>
> You can build a SearchMonkey infobar that is set to function on all URLs
> (just use "*" in your URL field.)
>
> For example, the Creative Commons SearchMonkey application:
>
> http://gallery.search.yahoo.com/application?smid=kVf.s
>
> (currently broken because of a recent change in the SearchMonkey PHP API
> that we need to address, so here's a photo:
>
> http://www.flickr.com/photos/ysearchblog/2869419185/
> )
>
> By adding the CC RDFa markup to your page, it will show up with the
> infobar in Yahoo searches.

Ah, hadn't considered a net-wide SearchMonkey script.  Interesting.

This brings up different issues, however.  Something I see
immediately: Say I'm a scammer.  I know that the CC SearchMonkey app
is in wide use (pretend, here).  I start putting CC-RDF data in spam
blog comments, with my own spammy stuff in the relevant fields.  Now
people don't even have to click on the blog link in the search results
and read my obviously spammy comment to be introduced to my offers for
discount Viagra!  They'll just see a little CC bar, click on it to
have it open in-place, and there I am.  I could even hide my link in
legitimate license data, so that people only hit my malicious site
when they click the link to see more information about the license.

Issues like these make wide-scale auto-trusted use of metadata
difficult.  It also makes me more reluctant to want it in the spec
yet.  I'd rather see the community work out these problems first.  It
may be that there's a relatively simple solution.  It may be that the
crawlers can reliably distinguish between ham and spam CC data.  But
then, it may be that there *is* no good solution enabling us to use
this approach, and this kind of metadata on arbitrary sites just can't
be trusted.

I, personally, don't know the answer to this yet.  I suspect that you
don't, either; if the arbitrary-site CC infobar works at all, it's
because few people *use* CC RDF yet, and so it's still limited to a
community with implicit trust.

> So site-specific microformats are clearly less powerful. And
> vocabulary-specific microformats, while useful, are also not as useful
> here (consider a SearchMonkey application that picks up CC-licensed
> items, be they video, audio, books, scientific data, etc... Different
> microformats = development hell.)

Indeed, they are less powerful.  As I explored above, though, too much
power can be damning. It may be that the site-specific little-m
microformat (or something equivalent, allowing a developer to extract
metadata through actively targeting site structure) is powerful enough
to be useful, but weak enough to *remain* useful in the face of abuse.

(Also, I know CC is sort of the darling of the RDFa community, but
there's significant enough debate over in-band vs out-of-band
licensing info, etc. that detracts from the core issues we're trying
to discuss here that it's probably not the best example to use.)

> Have you read the RDFa Primer?
> http://www.w3.org/TR/xhtml-rdfa-primer/
>
> It describes (pre-SearchMonkey) the kind of applications that can be
> built with RDFa. SearchMonkey is an ideal example, but it's by no means
> the only one.

Yup; I was an active participant in this discussion when it started
last August.  The example applications discussed in the paper,
unfortunately, are precisely the kind where trusting metadata is
likely a *bad* idea.  For example, finding reviews of shows produced
by friends of Alice, using foaf and hreview, is rife with opportunity
for spamming.  SearchMonkey seems to avoid this for the most part;
when designing applications for particular URLs, at least, you are
relying on relatively trustworthy data, not arbitrary data scattered
across the web.  Perhaps something similar has application within
trusted networks, but in that case it comprises a completely different
use case than what SearchMonkey hits, with possibly different
requirements.

~TJ


From bzbarsky at MIT.EDU  Fri Jan  9 14:46:06 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 09 Jan 2009 17:46:06 -0500
Subject: [whatwg] Origins, reprise
In-Reply-To: <7789133a0901091316g58f02b51m57f3e4697fae8799@mail.gmail.com>
References: <49679AA7.2020902@mit.edu>
	<7789133a0901091316g58f02b51m57f3e4697fae8799@mail.gmail.com>
Message-ID: <4967D3AE.7030501@mit.edu>

Adam Barth wrote:
> On Fri, Jan 9, 2009 at 10:42 AM, Boris Zbarsky <bzbarsky at mit.edu> 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 authority component which is the 
IMAP server.  At the same time, each message needs to be treated as a 
separate trust domain.

Similar for the proposed nntp URIs [2].

-Boris

[1] http://www.rfc-editor.org/rfc/rfc5092.txt
[2] http://tools.ietf.org/html/draft-ellermann-news-nntp-uri-11


From henry.story at bblfish.net  Fri Jan  9 14:57:43 2009
From: henry.story at bblfish.net (Story Henry)
Date: Fri, 9 Jan 2009 23:57:43 +0100
Subject: [whatwg] <keygen>
In-Reply-To: <C3CC87D2-2781-4F23-953B-FBD48639E556@bblfish.net>
References: <C3CC87D2-2781-4F23-953B-FBD48639E556@bblfish.net>
Message-ID: <132567F9-FD6A-4107-A74F-E442A0959140@bblfish.net>

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 <keygen> tag. As it happens we are working  
> on a protocol
> foaf+ssl where keygen turns out to be extremely useful. It allows us  
> to create web services to give people very secure certificates which  
> can then be used to build a secure distributed social network based  
> on a web of trust.
>
> The foaf+ssl protocol works as it happens with most existing  
> browsers - though we have not done a detailed study of this yet (if  
> people could help this would be greatly appreciated). The protocol  
> is summarized here:
>
> http://www.w3.org/2008/09/msnws/papers/foaf+ssl.html
>
> And you can find more on my blog at http://blogs.sun.com/bblfish .
>
> The discussion on <keygen> which produces spkac public keys which it  
> sends to the server can be found on the foaf-protocols mailing list  
> archive under 'spkac'
>
> http://lists.foaf-project.org/pipermail/foaf-protocols/2009-January/date.html
>
> To tell you the truth I just discovered this tag recently myself,  
> wrote some code to test that it worked, found it to work on Opera,  
> Netscape, and Firefox, though it works slightly differently on each  
> platform.
>
> http://lists.foaf-project.org/pipermail/foaf-protocols/2009-January/000153.html
>
> I also put up a page on wikipedia:
>
> 	http://en.wikipedia.org/wiki/Spkac
>
> So please do keep the tag, and perhaps work on making it easier to  
> work with.
>
> 	Henry
>
> Blog: http://blogs.sun.com/bblfish
>
>
> Ian Hickson wrote on January 6 2009:
>> Over the years, several people (most of them bcc'ed) have asked for  
>> HTML5 to include a definition of <keygen>. Some have even gone as  
>> far as finding documentation on the element -- thank you. As I  
>> understand it based on the documentation, <keygen> basically  
>> generates a public/private asymmetric cryptographic key pair, and  
>> then sends the public component as its form value.  Unfortunately,  
>> this seems completely and utterly useless, as at no point does  
>> there seem to be any way to ever use the private component either  
>> for signing or for decrypting anything, nor does there appear to be  
>> a way to use the certificate for authentication. Without further  
>> information along these lines describing how to actually make  
>> practical use of the element, I do not intend to document <keygen>  
>> in the HTML5 specification. If anyone can fill in these holes that  
>> would be very helpful. Cheers,
>
>
>
>



From ben at adida.net  Fri Jan  9 15:13:14 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 15:13:14 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>	
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>	
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>	
	<4967B0D8.6020103@adida.net>	
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>	
	<4967BFFC.4080305@adida.net>
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
Message-ID: <4967DA0A.8040900@adida.net>

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 <title>, which is clearly
featured in search engine results?

-Ben


From jackalmage at gmail.com  Fri Jan  9 15:29:20 2009
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 9 Jan 2009 17:29:20 -0600
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967DA0A.8040900@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
	<4967BFFC.4080305@adida.net>
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
	<4967DA0A.8040900@adida.net>
Message-ID: <dd0fbad0901091529x1df7e349uf72e30604e69ebb8@mail.gmail.com>

On Fri, Jan 9, 2009 at 5:13 PM, Ben Adida <ben at adida.net> 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 <title>, which is clearly
> featured in search engine results?

Well, it's something that we probably want to keep in mind, because
it's so relevant for the success of any such proposal.  I wouldn't
want to lend support to a feature that turned out to be immediately
useless due to spam.  Lot of wasted effort on the WG's, Ian's, and
possibly browser developer's part.

To answer your specific question, <title> 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.

On the other hand, the hypothetical attack scenario I outlined was
about metadata that could be added to the page by external parties.

If we were today discussing adding <title> to HTML5 to help search
engines provide a short summary of a page, and part of the proposal
might allow blog commenters to change the title of pages on a whim,
I'd certainly be equally concerned.  ^_^

~TJ


From ian at hixie.ch  Fri Jan  9 15:37:30 2009
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 9 Jan 2009 23:37:30 +0000 (UTC)
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967DA0A.8040900@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk> 
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de> 
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com> 
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net> 
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com> 
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
	<4967BFFC.4080305@adida.net>
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
	<4967DA0A.8040900@adida.net>
Message-ID: <Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>

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 extraction is especially susceptible to spamming 
attacks, then it is unlikely to be useful for wide-scale automated data 
extraction.


> If so, where is the concern around <title>, which is clearly featured in 
> search engine results?

Nobody is suggesting that user agents derive any behavior from <title>, so 
it doesn't matter if <title> is spammed or not. The only effect would be 
some spam in the user's session history. Furthermore, <title> is page- 
wide, meaning that the actual page author would have to spam the page for 
it to be spamed. It is less likely for a user to intentionally visit a 
spammy page than for a user to visit a page that happens to contain spammy 
content embedded within it (e.g. in blog comments).

If browsers were expected to crawl all pages for all links and then 
populate the browser's interface with the most popular links, then one 
would quickly expect everyone's browsers to be advertising Viagra, porn 
sites, and the like. However, browsers don't do this kind of processing -- 
indeed, this kind of processing appears to be exactly what RDFa proponents 
are trying to enable (though to what end, I'm still trying to find out, 
since nobody has actually replied to all the questions I asked yet [1]).

Note that search engines aren't the problem here -- large operations like 
search engines are quite capable of running the massive processing 
required to filter spam. The problem is automated processing on the 
client, where those resources aren't available.

[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-December/018023.html

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ben at adida.net  Fri Jan  9 15:38:42 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 15:38:42 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <dd0fbad0901091529x1df7e349uf72e30604e69ebb8@mail.gmail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>	
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>	
	<4967B0D8.6020103@adida.net>	
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>	
	<4967BFFC.4080305@adida.net>	
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>	
	<4967DA0A.8040900@adida.net>
	<dd0fbad0901091529x1df7e349uf72e30604e69ebb8@mail.gmail.com>
Message-ID: <4967E002.1080305@adida.net>

Tab Atkins Jr. wrote:
> To answer your specific question, <title> 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 hand, the hypothetical attack scenario I outlined was
> about metadata that could be added to the page by external parties.

I thought your attack concerned both author markup and commenter markup.
But it seems we agree on author markup: no additional risk there.

So on to commenter markup.

Most blogging software already white-lists the HTML elements and
attributes they allow, otherwise they are easily hacked with XSS. This
means that, by default, most blogging software will strip RDFa from
comments, which is exactly the right approach, since comments should not
have authority over the structured data of the page.

-Ben


From ben at adida.net  Fri Jan  9 15:55:12 2009
From: ben at adida.net (Ben Adida)
Date: Fri, 09 Jan 2009 15:55:12 -0800
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
	<4967BFFC.4080305@adida.net>
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
	<4967DA0A.8040900@adida.net>
	<Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
Message-ID: <4967E3E0.4060204@adida.net>

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 wide-scale automated data 
> extraction.

It's no more susceptible to spam than existing HTML, as per my previous
response.

> Nobody is suggesting that user agents derive any behavior from <title>, so 
> it doesn't matter if <title> is spammed or not.

And RDFa does not mandate any specific behavior, only the ability to
express structure. The power lies in products like SearchMonkey that
make use of this structure with innovative applications.

Can one imagine tools that make poor use of this structured data so that
they incentivize spam? Absolutely. Is this the bar for HTML5? If bad or
poorly conceived applications can be imagined, then it's not in the
standard?

> It is less likely for a user to intentionally visit a 
> spammy page than for a user to visit a page that happens to contain spammy 
> content embedded within it (e.g. in blog comments).

You've done plenty of web security work, and I suspect you know well
that spammy RDFa is the least in a large set of problems that come with
accepting arbitrary markup in blog comments. This is a strawman.

> However, browsers don't do this kind of processing -- 
> indeed, this kind of processing appears to be exactly what RDFa proponents 
> are trying to enable (though to what end, I'm still trying to find out, 
> since nobody has actually replied to all the questions I asked yet [1]).

While client-side processing is indeed an important use case (Ubiquity,
Fuzzbot, etc...), it's not the only one. SearchMonkey, which you
continue to ignore, is an important use case.

Before I invest significant time in responding to your barrage of
questions, I'm looking for a hint of objective evaluation on your end. I
thought I saw an opportunity for productive discussion based on common
ground with SearchMonkey, but this has led again into a new and
close-to-bogus reason for blocking consideration of RDFa.

> Note that search engines aren't the problem here

Actually, we were discussing SearchMonkey, so I think it's very much the
context for this sub-thread. You continue to ignore SearchMonkey, for
reasons which, as I've pointed out in a response earlier today, are
factually incorrect.

-Ben


From ian at hixie.ch  Fri Jan  9 16:02:51 2009
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 10 Jan 2009 00:02:51 +0000 (UTC)
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967E3E0.4060204@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk> 
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de> 
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com> 
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net> 
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com> 
	<4967B0D8.6020103@adida.net>
	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>
	<4967BFFC.4080305@adida.net>
	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>
	<4967DA0A.8040900@adida.net>
	<Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
	<4967E3E0.4060204@adida.net>
Message-ID: <Pine.LNX.4.62.0901092358400.29785@hixie.dreamhostps.com>

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 others I'd missed.


> Before I invest significant time in responding to your barrage of 
> questions, I'm looking for a hint of objective evaluation on your end.

All I'm trying to do is evaluate things objectively. I don't know how much 
more I can "hint" towards this.

Indeed, every question I asked in the aforementioned e-mail had no reason 
_other_ than to enable me to objectively evaluate the proposals.


> > Note that search engines aren't the problem here
> 
> Actually, we were discussing SearchMonkey, so I think it's very much the 
> context for this sub-thread.

I meant that search engines weren't the problem when it came to spam. 
Search engines can deal with distributed spam. The techniques developed to 
combat distributed spam don't really work on the scale of a single user's 
machine and browser.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From danbri at danbri.org  Fri Jan  9 16:05:17 2009
From: danbri at danbri.org (Dan Brickley)
Date: Sat, 10 Jan 2009 01:05:17 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<4966AE40.3040600@email.it> <49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de> <4967AA14.2000503@adida.net>
	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>
	<4967B0D8.6020103@adida.net>	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>	<4967BFFC.4080305@adida.net>	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>	<4967DA0A.8040900@adida.net>
	<Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
Message-ID: <4967E63D.2000107@danbri.org>

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 for
> wide-scale automated data extraction is especially susceptible to spamming
> attacks, then it is unlikely to be useful for wide-scale automated data
> extraction.

I've been looking at such concerns a bit for RDFa. One issue (shared 
with HTML in general I think) is user-supplied content, eg. blog 
comments and 'rel=nofollow' scenarios).  Is there any way in HTML5 to 
indicate that a whole chunk of Web page is from an (in some 
to-be-defined sense) untrusted source?

I see http://www.whatwg.org/specs/web-apps/current-work/#link-type-nofollow

"The nofollow keyword indicates that the link is not endorsed by the 
original author or publisher of the page, or that the link to the 
referenced document was included primarily because of a commercial 
relationship between people affiliated with the two pages."

While I'm unsure about the "commercial relationship" clause quite 
capturing what's needed, the basic idea seems sound. Is there any 
provision (or plans) for applying this notion to entire blocks of 
markup, rather than just to simple hyperlinks? This would be rather 
useful for distinguishing embedded metadata that comes from the page 
author from that included from blog comments or similar.

Thanks for any pointers,

cheers,

Dan

--
http://danbri.org/


From alex.baldacchino at email.it  Fri Jan  9 20:35:27 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sat, 10 Jan 2009 05:35:27 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967E3E0.4060204@adida.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<4966AE40.3040600@email.it>
	<49673926.4020902@gmx.de>	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>	<4967A856.5010206@gmx.de>
	<4967AA14.2000503@adida.net>	<dd0fbad0901091214k7139705ei52d5583dfd339ee4@mail.gmail.com>	<4967B0D8.6020103@adida.net>	<dd0fbad0901091300v6b73402amf6b2801e6c391e81@mail.gmail.com>	<4967BFFC.4080305@adida.net>	<dd0fbad0901091413h4039d292l45b0c53cebf435dd@mail.gmail.com>	<4967DA0A.8040900@adida.net>	<Pine.LNX.4.62.0901092328570.29785@hixie.dreamhostps.com>
	<4967E3E0.4060204@adida.net>
Message-ID: <4968258F.0@email.it>

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 unlikely to be useful for wide-scale automated data 
>> extraction.
>>     
>
> It's no more susceptible to spam than existing HTML, as per my previous
> response.
>
>   

Perhaps this is why general purpose search engines do not rely 
(entirely) on metadata and markup semantics to classify content, nor 
does Yahoo with SearchMonkey. SearchMonkey documentation points out that 
metadata never affects page ranks, nor is semantics interpreted for any 
purpose; metadata only affects additional informations presented to the 
user at the user will, and if the user chose to get informations of a 
certain kind (gathered by a certain data service), thus spammy metadata 
can be thought as circumscribed in this case, they might corrupt 
SearchMonkey additional data, but not the user's overall experience with 
the search engine. From this point of view, SearchMonkey is some kind of 
wide-range but small-scale use case (with respect to each tool and each 
site the user might enable), because the user can easily choose which 
sources to trust (e.g. which data services to use, or which sites to 
look for additional infos), and in any case he can get enough infos 
without metadata.

On the other hand, a client UA implementing a feature entirely based on 
metadata couldn't easily circumscribe abused metadata and bring valid 
informations to the user attention, nor could the average user take 
easily trusted and spammy sites apart, because he wouldn't understand 
the problem (and a site with spammy metadata might still contain 
informations users were interested in previously, or in a different 
context), whereas in SearchMonkey the average user would notice 
something doesn't work in enhanced results, but he'd also get the basic 
infos he was looking for. Thus there are different requirements to be 
taken into account for different scenarios (SearchMonkey and client UA 
are such different scenarios)

Moreover, SearchMonkey is a kind of centralised service based on 
distributed metadata, it doesn't need collaboration by any other UA 
(that is, it doesn't need support for metadata in other software) by 
default (whereas it allows custom data services to autonomously extract 
metadata, but always for the purposes of SearchMonkey), it only requires 
that web sites adhering to the project (or just willing to provide 
additional infos) embed some kind of metadata only for the purpose of 
making them available to SearchMonkey services, or at least that authors 
create appropriate metadata and send them to Yahoo (in the form of 
dataRSS embedded in a Atom document). That is, SearchMonkey seems to me 
a clear example of a use case for metadata not requiring any changes to 
html5 spec, since any kind of supported metadata are used by 
SearchMonkey as if they were custom, private metadata; whatever happens 
to such metadata client-side, even if they're just stripped by a 
browser, doesn't really matter.

Furthermore, SearchMonkey supports several kinds of metadata, not only 
RDFa, but also eRDF, microformats and dataRSS external to the document. 
So, why should SearchMonkey be the reason to introduce explicit support 
to RDFa and not also for eRDF, which doesn't require new attributes, but 
just a parser? One might think one solution is better than the other, 
and this might be true in theory, but what really counts is what people 
do find easier to use, and this might be determined by experience with 
SearchMonkey (that is, let's see what people use more often, then decide 
what's more needed).

Moreover, RDFa is thought for xhtml, thus it can't be introduced in html 
serialization just by defining a few new attributes: a processor would 
or might need some knowledge over /namespaces/, thus the whole "family" 
of *xmlns* attributes (with and without prefixes) should be specified 
for use with the html serialization, unless an alternative mechanism, 
similar to the one chosen for eRDF, were defined, and maybe such would 
result in a new, hybrid mechanism (stitching together pieces from eRDF 
and RDFa). Buf if we introduce xmlns and xmlns:<prefix> into html 
serialization, why not also prefixed attributes? That is, can RDFa be 
introduced into html serialization "as is", without resorting to the 
whole xml extensibility? This should be taken into account as well, 
because just adding new attributes to the language might work fine for 
xml-serialized documents, but might not for html-serialized ones. This 
means RDFa support might be more difficult than it may seem at first 
glance, whereas it might not be needed for custom and/or small scale use 
cases (and I think SearchMonkey is one such case).

>> Nobody is suggesting that user agents derive any behavior from <title>, so 
>> it doesn't matter if <title> is spammed or not.
>>     
>
> And RDFa does not mandate any specific behavior, only the ability to
> express structure. The power lies in products like SearchMonkey that
> make use of this structure with innovative applications.
>
> Can one imagine tools that make poor use of this structured data so that
> they incentivize spam? Absolutely. Is this the bar for HTML5? If bad or
> poorly conceived applications can be imagined, then it's not in the
> standard?
>
>   

I think the right question should be whether there are effective counter 
measures to circumscribe bad uses and make possible damages less 
significant then advantages from good uses. When a feature in the 
standard is thought to be a possible security (or privacy) issue, 
counter-measures are proposed. Since spam is a possible immediate issue 
for abused metadata, especially in wide-scale and automated data 
extraction, we should also think to possible counter-measures to be 
specc'ed out along with RDFa attributes.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Innammorarsi ? facile con Meetic, milioni di single si sono iscritti, si sono conosciuti e hanno riscoperto l'amore. Tutto con Meetic, prova anche tu!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8292&d=10-1


From mail at tobyinkster.co.uk  Sat Jan 10 05:51:26 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sat, 10 Jan 2009 13:51:26 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
Message-ID: <A2E0CDEC-2E3A-4A62-A062-96B1B4FB0682@tobyinkster.co.uk>

Dan Brickley wrote:

> While I'm unsure about the "commercial relationship" clause quite
> capturing what's needed, the basic idea seems sound. Is there any
> provision (or plans) for applying this notion to entire blocks of
> markup, rather than just to simple hyperlinks? This would be rather
> useful for distinguishing embedded metadata that comes from the page
> author from that included from blog comments or similar.

While that might be useful for natural language processing, for RDFa  
it is actually completely unneeded. The syntax of RDFa allows for  
blocks of markup to be made "invisible" by making an ancestor node  
into an XMLLiteral.

For example, a comment might be marked up as:

<section typeof="atom:Entry" xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:atom="http://bblfish.net/work/atom-owl/2006-06-06/#">
   <address rel="atom:author">
     On <time property="atom:published" content="2009-01-10"
     >10 Jan 2009</time>,
     <a property="foaf:name" rel="foaf:page"
     href="http://joe.example.com">Joe Bloggs</a> wrote:
   </address>
   <div rel="atom:content">
     <blockquote property="atom:xhtml">
       <!-- The comment goes here. -->
     </blockquote>
   </div>
</section>

The RDFa processing instructions say that as the blockquote doesn't  
have an explicit datatype set, it is to be treated entirely as a  
string literal (if it doesn't have any child elements) or an XML  
literal (if it does), and that parsers must not look inside it for  
triples. Thus spammers can't use the comment form for stuffing  
triples into the page.

It should be noted in this case that RDFa also allows natural  
language parsers to be made more useful. By looking at the RDFa which  
marks up the author's name and website, they may be able to determine  
that the comment has been written by someone other than the page's  
main author, and thus not afford it the same level of trust granted  
to the rest of the page. So the natural language processing can  
benefit from RDFa.

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



From alex.baldacchino at email.it  Sat Jan 10 09:54:23 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sat, 10 Jan 2009 18:54:23 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <A2E0CDEC-2E3A-4A62-A062-96B1B4FB0682@tobyinkster.co.uk>
References: <A2E0CDEC-2E3A-4A62-A062-96B1B4FB0682@tobyinkster.co.uk>
Message-ID: <4968E0CF.30801@email.it>

Toby A Inkster ha scritto:
>
> It should be noted in this case that RDFa also allows natural language 
> parsers to be made more useful. By looking at the RDFa which marks up 
> the author's name and website, they may be able to determine that the 
> comment has been written by someone other than the page's main author, 
> and thus not afford it the same level of trust granted to the rest of 
> the page. So the natural language processing can benefit from RDFa.
>

That's true only if one can assume metadata are trustful, but they are 
only if they can be under a strict control, that is on a small-scale 
application. On a wider scale, one needs to make the opposite 
assumption, because it would or might be more common to find fake 
metadata with "honest" content (the prose of an advertisement does not 
lie, but related metadata can tell it's a different think to cheat a 
metadata-based UA), either because a site author can be a party to the 
spammer, or because authors can mess up metadata (yeah, they can mess up 
html code too, but that's either not a problem, because a UA can present 
the content as well, or it is but it might damage the author more than 
it may harm the user). If metadata are created/used for external 
consumption, they can be just ignored by authors, who instead may just 
copy&paste code or reuse templates in different contexts, without being 
able to set proper metadata for the new content. Thus UAs can't rely on 
metadata /in general/, while they might /in some/, small-scale scenarios.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8547&d=10-1


From kornel at geekhood.net  Sat Jan 10 12:42:37 2009
From: kornel at geekhood.net (=?UTF-8?Q?Kornel_Lesi=C5=84ski?=)
Date: Sat, 10 Jan 2009 20:42:37 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4966AE40.3040600@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>
	<495F97A9.1080602@email.it> <op.um7lz7ufwxe0ny@widsithpro.lan>
	<4966AE40.3040600@email.it>
Message-ID: <2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>

On 09.01.2009, at 01:54, 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

One can also use <link rel="alternate" href="description.rdf">. I  
don't see why RDF metadata must be in the HTML document. It could be  
in a separated file, maybe embedded in RSS/Atom feeds (RSS1.0 is  
pretty close already).

Websites that have a lot of useful data to share usually keep it in a  
database, and this allows them to easily generate RDF as separate  
documents without risk of getting out of sync with the HTML version.

IMHO even RDFa metadata is invisible, and errors in RDFa wouldn't be  
much easier to spot than erorrs in external RDF files, e.g.:

<section typeof="atom:Entry" xmlns:foaf="http://xmlns.com/foaf/1.0/"
xmlns:atom="http://purl.org/atom/ns#">
  <address rel="atom:author">
    On <time property="atom:published" content="2009-01-10"
     >10 Jan 2009</time>,
    <a property="foaf:name" rel="foaf:page"
    href="http://joe.example.com">Joe Bloggs</a> wrote:
  </address>

-- 
regards, Kornel





From alex.baldacchino at email.it  Sat Jan 10 18:01:13 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 11 Jan 2009 03:01:13 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <49676581.9060301@digitalbazaar.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>	<op.um7lz7ufwxe0ny@widsithpro.lan>
	<4966AE40.3040600@email.it> <49676581.9060301@digitalbazaar.com>
Message-ID: <496952E9.7010708@email.it>

Manu Sporny ha scritto:
> 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 plugins, or scripts to be
>> embedded in a webbapp, and working on top of other feature might work
>> fine and lead to a better, native support by all vendors, yet limited to
>> an API for custom applications
>>     
>
> There seems to be a bit of confusion over what RDFa can and can't do as
> well as the current state of the art. We have created an RDFa Firefox
> plugin called Fuzzbot (for Windows, Linux and Mac OS X) that is a very
> rough demonstration of how an browser-based RDFa processor might
> operate. If you're new to RDFa, you can use it to edit and debug RDFa
> pages in order to get a better sense of how RDFa works.
>
>   

The concern is about every kind of metadata with respect to their 
possible uses; but, while it's been stated that Microforamts (for 
instance) don't require any purticular support by UAs (thus they're 
backward compatible), RDFa would be a completely new feature, thus html5 
specification should say what UAs are espected to do with such new 
attributes.

Shall UAs just "accept" them and expose an API to extract triples, so 
that a web application can build a query mechanism upon such an API? 
This might work fine, and fulfill small-scale scenarios, such as 
organization-wise data modelling and interchanging, as suggested by 
Charls McCathieNevile; this can also be accomplished by an external plugin.

Shall UAs (browsers) also provide an interface to view bare triples (as 
does Fuzzbot), as a kind of debugging tool? As above.

Shall UAs (browsers) also provide metadata-based features, such as a 
query interface to look for content in a local history? This is a wider 
scale application, and also a use case where problems may arise. From 
this angle, metadata can't be assumed as reliable apriori (instead, 
their reliability is uncertain), nor can users be deemed capable to 
understand the problem and filter out wrong/misused/abused metadata (in 
general). This is the scenario were spammy metadata may become an issue. 
For instance, some code like,

<div  typeof="foaf:Person">
    <p property="foaf:name" content="Manu Sporny">We sell
        <a href="http://www.cheatingcarseller.com" 
rel="foaf:homepage">cars</a>
    </p>
</div>

would produce the following triples,

_:bnode0     rdf:type     http://xmlns.com/foaf/0.1/Person
_:bnode0     foaf:homepage     http://www.cheatingcarseller.com
_:bnode0     foaf:name     Manu Sporny

(this is exactly what Fuzzbot outputs)

thus, a metadata-based search feature might output a link to a 
"metadata-spammy" site when queried for "Manu Sporny". That is, cheating 
a metadata-based bot by the mean of fake metadata can be very easy.

Metadata-based features, but this is true for most of xml-related 
technologies (such as RDF/RDFa), work fine if properly used. Unluckily, 
"things must be used properly to work fine" is not the basic principle 
of the web (and this is specially true for html and related 
technologies), which instead has always been about "people will mess 
everything up, but UAs will work fine as well", that is "robustness 
before all, as far as possible". For what concerns html serialization, 
in particular, I'd consider some code like,

<p typeof="cal:Vevent">
  I'm holding
  <span property="cal:summary">
    one last summer Barbecue
  <!-- /span -->, to meet friends and have a party before the end of 
holidays
  on
  <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
        datatype="xsd:dateTime">
    September 16th at 4pm
  </span>.
</p>

(taken from <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/> and 
purposedly modified)

which is rendered properly, but produces,

_:bnode1     rdf:type     http://www.w3.org/2002/12/cal/icaltzd#Vevent
_:bnode1     cal:dtstart     2007-09-16T16:00:00-05:00
_:bnode1     cal:summary     one last summer Barbecue , to meet friends 
and have a party before the end of holidays on <span 
xmlns:cal="http://www.w3.org/2002/12/cal/icaltzd#" 
xmlns:foaf="http://xmlns.com/foaf/0.1/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema#" 
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
datatype="xsd:dateTime" datatype="xsd:dateTime" 
content="2007-09-16T16:00:00-05:00" property="cal:dtstart">September 
16th at 4pm</span>

(taken from Fuzzbot keeping namespace declarations in the root element; 
without xmlns:* attributes all triples are lost)

which is not the desired result. Perhaps it might work better as an xml 
feature on a "strict" xml parser (aborting with an error because of a 
missing end tag), even considering RDFa relies on namespaces (thus, 
adding RDFa attributes to HTML5 spec would require some features from 
xml extensibility to be added to html serialization). But RDFa in an 
XHTML document might look like "rdfa:about", "rdfa:property", 
"rdfa:content", and so on, that is as an external module, thus not 
requiring any changes to the spec.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Incrementa la visibilita' della tua azienda con l'invio di newsletter e campagne email marketing.
* Con investimento di soli 250 Euro puoi incrementare la tua visibilita'
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8350&d=11-1


From alex.baldacchino at email.it  Sat Jan 10 18:51:16 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 11 Jan 2009 03:51:16 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>
	<495F97A9.1080602@email.it> <op.um7lz7ufwxe0ny@widsithpro.lan>
	<4966AE40.3040600@email.it>
	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
Message-ID: <49695EA4.1060302@email.it>

Kornel Lesi?ski ha scritto:
> On 09.01.2009, at 01:54, 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
>
> One can also use <link rel="alternate" href="description.rdf">. I 
> don't see why RDF metadata must be in the HTML document. It could be 
> in a separated file, maybe embedded in RSS/Atom feeds (RSS1.0 is 
> pretty close already).
>
> Websites that have a lot of useful data to share usually keep it in a 
> database, and this allows them to easily generate RDF as separate 
> documents without risk of getting out of sync with the HTML version.
>

In principle, I agree (also, Atom 1.0 embedding RDFa as dataRSS is the 
base of SearchMonkey). But if people feel the need to embed metadata in 
their documents and to use them as a distributed database, well, let's 
give them a chance to do so. :-P

eRDF might be a working compromise, because it doesn't need any changes 
to the spec; RDFa covers a wider range of RDF semantics, but requires 
new attributes and also namespaces (a sort of hybrid beteween them might 
avoid the need to bring namespaces - xmlns:* attributes - into html 
serialization). My suggestion was meant as a mean to test RDFa in HTML 
documents without changing the spec (perhaps in conjunction with 
data-xmlns-*, data-xmlns-prefixes="rdfa foaf <whatever>" to "emulate" 
namespaces - an ugly hack, I know, but at least would avoid changes to 
html serialization, at least in a test phase) -- even if I think that 
xml serialization should work better for such rdf metadata.

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8549&d=11-1


From bhawkeslewis at googlemail.com  Sun Jan 11 01:41:39 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sun, 11 Jan 2009 09:41:39 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <49695EA4.1060302@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it>
Message-ID: <4969BED3.9010401@googlemail.com>

On 11/1/09 02:51, Calogero Alex Baldacchino wrote:
> eRDF might be a working compromise, because it doesn't need any changes
> to the spec

It's not possible to author conforming HTML5 that functions as eRDF 
since eRDF requires a 'profile' attribute, but HTML5 has removed the 
attribute.

http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml

; RDFa covers a wider range of RDF semantics, but requires
> new attributes and also namespaces (a sort of hybrid beteween them might
> avoid the need to bring namespaces - xmlns:* attributes - into html
> serialization).

To avoid xmlns:* attributes, one could drop CURIEs in the text/html 
serialization and use markup like:

<div>
   <div about="http://dbpedia.org/resource/Albert_Einstein">
     ...
   </div>
</div>

instead of

<div xmlns:db="http://dbpedia.org/">
   <div about="[db:resource/Albert_Einstein]">
     ...
   </div>
</div>

There's no data loss.

> My suggestion was meant as a mean to test RDFa in HTML
> documents without changing the spec (perhaps in conjunction with
> data-xmlns-*, data-xmlns-prefixes="rdfa foaf <whatever>" to "emulate"
> namespaces - an ugly hack, I know, but at least would avoid changes to
> html serialization, at least in a test phase) -- even if I think that
> xml serialization should work better for such rdf metadata.

I really can't see anybody violating the spec in that way rather than 
violating the spec by just adding the RDFa attributes outright, 
especially given that there are already people publishing these 
attributes in text/html so the "namespace" has already been polluted and 
we already have services like SearchMonkey not only using these 
attributes but promoting them. It may therefore already be problematic 
for a future version of HTML to use these attributes as extension points 
without breaking existing sites. The "test" is already in progress, for 
better or worse. HTML5 conformance checkers don't have to bless this 
test, of course, any more than CSS validators have to give the all clear 
to vendor-specific properties.

Moreover, the damage done by immediately breaking the principle that 
data-* should be for private use only and turning it into a distributed 
extension point may be worse than the alternatives.

--
Benjamin Hawkes-Lewis


From mail at tobyinkster.co.uk  Sun Jan 11 04:01:58 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Sun, 11 Jan 2009 12:01:58 +0000
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Message-ID: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>

Calogero Alex Baldacchino wrote:

> The concern is about every kind of metadata with respect to their
> possible uses; but, while it's been stated that Microforamts (for
> instance) don't require any purticular support by UAs (thus they're
> backward compatible), RDFa would be a completely new feature, thus  
> html5
> specification should say what UAs are espected to do with such new
> attributes.

RDFa doesn't require any special support beyond the special support  
that is required for Microformats. i.e. nothing. User agents are free  
to ignore the RDFa attributes. In that sense, RDFa already "works" in  
pretty much every existing browser, even going back to dinosaurs like  
Mosaic and UdiWWW.

Agents are of course free to offer more than that. Look at what they  
do with Microformats: Firefox for instance offers an API to handle  
Microformats embedded on a page; Internet Explorer offers its "Web  
Slices" feature.

> For what concerns html serialization, in particular, I'd consider  
> some code like [...] which is rendered properly


Is it though? Try adding the following CSS:

	span[property="cal:summary"] { font-weight: bold; }

And you'll see that CSS doesn't cope with a missing ending tag in  
that situation either.

If you miss out a non-optional end tag, then funny things will happen  
- RDFa isn't immune to that problem, but neither is the DOM model,  
CSS, microformats, or anything else that relies on knowing where  
elements end. A better comparison would be a missing </p> tag, which  
is actually allowed in HTML, and HTML-aware RDFa processors can  
generally handle just fine.

> considering RDFa relies on namespaces (thus,
> adding RDFa attributes to HTML5 spec would require some features from
> xml extensibility to be added to html serialization).


RDFa *does not* rely on XML namespaces. RDFa relies on eight  
attributes: about, rel, rev, property, datatype, content, resource  
and typeof. It also relies on a CURIE prefix binding mechanism. In  
XHTML and SVG, RDFa happens to use XML namespaces as this mechanism,  
because they already existed and they were convenient. In non-XML  
markup languages, the route to define CURIE prefixes is still to be  
decided, though discussions tend to be leaning towards something like:

<html prefix="dc=http://purl.org/dc/terms/ foaf=http://xmlns.com/foaf/ 
0.1/">
<address rel="foaf:maker" rev="foaf:made">This document was made by  
<a href="http://joe.example.com" typeof="foaf:Person"  
rel="foaf:homepage" property="foaf:name">Joe Bloggs</a>.</address>
</html>

This discussion seems to be about "should/can RDFa work in HTML5?"  
when in fact, RDFa already can and does work in HTML5 - there are  
approaching a dozen interoperable implementations of RDFa, the  
majority of which seem to handle non-XHTML HTML. Assuming that people  
see value in RDFa, and assuming that the same people see value in  
using HTML5, then these people will use RDFa in HTML5. The question  
we should be discussing is not "should it work?" (because it already  
does), but rather, "should it validate?"

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





From alex.baldacchino at email.it  Sun Jan 11 08:52:40 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Sun, 11 Jan 2009 17:52:40 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4969BED3.9010401@googlemail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
Message-ID: <496A23D8.9090901@email.it>

Benjamin Hawkes-Lewis ha scritto:
> On 11/1/09 02:51, Calogero Alex Baldacchino wrote:
>> eRDF might be a working compromise, because it doesn't need any changes
>> to the spec
>
> It's not possible to author conforming HTML5 that functions as eRDF 
> since eRDF requires a 'profile' attribute, but HTML5 has removed the 
> attribute.
>

I didn't noticed that before, thanks for the info :-)

However, actually it's the same for RDFa attributes, because they're not 
in the spec. From this point of view, introducing six new attributes, or 
resorting to an older one is not very different, thus (again) why RDFa 
and not eRDF? Or why not both? Or not also RDFa embedded in Atom 
embedded, in turn, in HTML (like SVG or MathML)? It seems to me, for 
instance, that at this stage SearchMonkey might be a reason to consider 
all of them.

>
> ; RDFa covers a wider range of RDF semantics, but requires
>> new attributes and also namespaces (a sort of hybrid beteween them might
>> avoid the need to bring namespaces - xmlns:* attributes - into html
>> serialization).
>
> To avoid xmlns:* attributes, one could drop CURIEs in the text/html 
> serialization and use markup like:
>
> <div>
>   <div about="http://dbpedia.org/resource/Albert_Einstein">
>     ...
>   </div>
> </div>
>
> instead of
>
> <div xmlns:db="http://dbpedia.org/">
>   <div about="[db:resource/Albert_Einstein]">
>     ...
>   </div>
> </div>
>
> There's no data loss.
>

Well, that's a chance, of course, but that's *not* RDFa as specified by 
W3C; for instance, @property is specified as accepting _only_ CURIEs 
(whereas @about can accept also URIs - and eRDF allows curies, even if 
in a different format than what specified for RDFa and what is used for 
XML in general). That is, to do that not one, but _two_ specifications 
need to be changed, current HTML5 (which is a draft, thus  not a 
problem) and RDFa (which now is a Recommendation, thus, might it be more 
difficoult? should a different specification be derived?), unless we 
want that to be just an unofficial, yet widely accepted, convention - 
and I think that an unofficial convention is worth the others (any 
processors conforming to standard RDFa would need deep changes to cope 
with that - it doesn't work in Fuzzbot when CURIEs are expected, for 
instance). I'm the first to say that my suggestion was an ugly hack, but 
at least it would have been working and conformant without changing 
anything.

>> My suggestion was meant as a mean to test RDFa in HTML
>> documents without changing the spec (perhaps in conjunction with
>> data-xmlns-*, data-xmlns-prefixes="rdfa foaf <whatever>" to "emulate"
>> namespaces - an ugly hack, I know, but at least would avoid changes to
>> html serialization, at least in a test phase) -- even if I think that
>> xml serialization should work better for such rdf metadata.
>
> I really can't see anybody violating the spec in that way rather than 
> violating the spec by just adding the RDFa attributes outright, --

Indeed, current specs are violated, and I was just considering a way to 
use RDFa without such violations before deciding if it's worth to be 
added to the spec, no more (and I don't want to push that hack anymore, 
just trying to point out my aim).

> --especially given that there are already people publishing these 
> attributes in text/html so the "namespace" has already been polluted 
> and we already have services like SearchMonkey not only using these 
> attributes but promoting them.

It seems to me that SearchMontky doesn't promote RDFa more than it 
promotes Microformats, eRDF and dataRSS (RDFa embedded in external Atom 
feeds). It's also a very recent feature, and I really can't guess which 
kind of RDF serialization is going to "win the battle" (that is, 
choosing one against the others *might* be a premature choice right now, 
as well as introducing all of them).

> It may therefore already be problematic for a future version of HTML 
> to use these attributes as extension points without breaking existing 
> sites. The "test" is already in progress, for better or worse. HTML5 
> conformance checkers don't have to bless this test, of course, any 
> more than CSS validators have to give the all clear to vendor-specific 
> properties.

It's the same with every possible existing custom (non-standard) 
attributes and elements out there, since there is no standard for them, 
and instead data-* has been created; it's also the same for accesskey, 
actually, since it's not in current spec (whereas it was in HTML4). 
After all, support for unknown attributes/elements has never been a 
standard "de jure", but more of a quirk, and there are no grants it will 
work fine in the future (as well as actually it doesn't work 
consistently for unknown elements cross-browsers -- there are strong 
differences between IE and other browsers with this respect).

Moreover, the use of such attributes /for the purposes of SearchMonkey/ 
is a very, very custom use case, since they're used just for server-side 
computations, thus no collaboration is required by other UAs; if 
browsers just ignored and dropped such attributes (as they do with 
unknown, proprietary CSS extensions), no page would be broken, whereas 
SearchMonkey would work as fine. Problems might arise if they were used 
in different contexts (e.g. as CSS selectors - but dropping unknown CSS 
rules is allowed by CSS spec), but who cares of them might just run a 
regex tool to map them to a new, standard-compliant version (given that, 
for instance, "data-rdfa-about", "rdfa:about" and "about" are in a 
1-to-1 correspondence, thus such might be done very easily by UAs as a 
quirk).

 From this point of view, SearchMonkey might use its own custom dataset 
and model without any changes to its functionalities (AIUI, the basic 
format for RDF metadata in SearchMonkey is dataRSS). Since there are 
standards for embedding RDF into (x)html documents, it just makes sense 
to support them all for Yahoo.

>
> Moreover, the damage done by immediately breaking the principle that 
> data-* should be for private use only and turning it into a 
> distributed extension point may be worse than the alternatives.
>
> -- 
> Benjamin Hawkes-Lewis

I really don't see the problem if a *custom* convention became widely 
accepted and reused by other people (given that my idea started from a 
Charls McCathieNevile's mail presenting small-scale scenarios, such as 
organizations' internal use and external interchange with other selected 
organizations, as a main context for RDFa - and I've never said HTML 
specification should even mention it, I was thinking to it just as an 
unofficial convention to experiment with in such scenarios).

I really can't get, right now, why it should be different, for instance, 
from the case of a freely reusable widget using a custom data model 
based on private data-* attributes inserted by people in thousands of 
websites (the widget with relitive metadata, I mean), then liked by 
other people and reused in different contexts (the same data model based 
on data-*, now), unless we agree this should be avoided, but I can't 
guess how to prevent people from reusing a "private-only" data model 
they happened to like (unless it resulted in a copyright infringment, 
but I'm not sure this may happen because of the mere use of the same 
name for some "variables" elaborated by a similar script, yet different 
in source code -- given that copyright is evaluated at source code 
level, not per the resulting functionalities, as far as I know).

WBR, Alex
 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Partecipa al concorso Danone Activia e vinci MacBook Air e Nokia N96. Prova
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8552&d=11-1


From bhawkeslewis at googlemail.com  Sun Jan 11 09:13:58 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Sun, 11 Jan 2009 17:13:58 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <496A23D8.9090901@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it>
Message-ID: <496A28D6.90104@googlemail.com>

On 11/1/09 16:52, Calogero Alex Baldacchino wrote:

> Well, that's a chance, of course, but that's *not* RDFa as specified by
> W3C; for instance, @property is specified as accepting _only_ CURIEs

Good point; I hadn't spotted that.

> It's the same with every possible existing custom (non-standard)
> attributes and elements out there, since there is no standard for them,
> and instead data-* has been created;

Emphatically, data-* has been created for private use data encoding 
(basically for scripting purposes) not as a replacement for the existing 
practices of adding new elements and attributes to HTML without going 
through W3C/WHATWG.

Existing custom attributes intended for use by scripts (e.g. "action" in 
Gmail and Yahoo! Mail), have a direct migration path open for them (i.e. 
to "data-action" or a HTML5-native feature). Proprietary attributes 
intended for use by user agents (e.g. "autocomplete"), on the other 
hand, must be adopted by HTML5 if they are not to be remain non-conforming.

> it's also the same for accesskey,
> actually, since it's not in current spec (whereas it was in HTML4).

I suspect the behavior for "accesskey" will ultimately be defined by the 
spec, whether or not it is made conforming.

> After all, support for unknown attributes/elements has never been a
> standard "de jure", but more of a quirk

Depends what you mean by "support" I guess.

> I really don't see the problem if a *custom* convention became widely
> accepted and reused by other people

Then you I think you don't agree with the fundamental design principle 
of the "data-*" attribute. The theory is that extensions to HTML benefit 
from going through a community process like WHATWG or W3C, and blessing 
extension points encourages people to circumvent that process, with the 
result that browsers have to support poorly designed features in order 
to have an interoperable web.

> I really can't get, right now, why it should be different, for instance,
> from the case of a freely reusable widget using a custom data model
> based on private data-* attributes inserted by people in thousands of
> websites (the widget with relitive metadata, I mean), then liked by
> other people and reused in different contexts (the same data model based
> on data-*, now)

Reuse of "data-*" by DHTML widgets would not impose any additional 
requirements on user agents, so it would be fine from the perspective 
elaborated above. It wouldn't change the language by the back door.

--
Benjamin Hawkes-Lewis


From mart at degeneration.co.uk  Sun Jan 11 16:28:50 2009
From: mart at degeneration.co.uk (Martin Atkins)
Date: Sun, 11 Jan 2009 16:28:50 -0800
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
Message-ID: <496A8EC2.7070403@degeneration.co.uk>

Toby A Inkster wrote:
> Calogero Alex Baldacchino wrote:
> 
>> The concern is about every kind of metadata with respect to their
>> possible uses; but, while it's been stated that Microforamts (for
>> instance) don't require any purticular support by UAs (thus they're
>> backward compatible), RDFa would be a completely new feature, thus html5
>> specification should say what UAs are espected to do with such new
>> attributes.
> 
> RDFa doesn't require any special support beyond the special support that 
> is required for Microformats. i.e. nothing. User agents are free to 
> ignore the RDFa attributes. In that sense, RDFa already "works" in 
> pretty much every existing browser, even going back to dinosaurs like 
> Mosaic and UdiWWW.
> 
> Agents are of course free to offer more than that. Look at what they do 
> with Microformats: Firefox for instance offers an API to handle 
> Microformats embedded on a page; Internet Explorer offers its "Web 
> Slices" feature.
> 

If it is true that RDFa can work today with no ill-effect in downlevel 
user-agents, what's currently blocking its implementation? Concern for 
validation?

It seems to me that many HTML extensions are implemented first and 
specified later[1], so perhaps it would be in the interests of RDFa 
proponents to get some implementations out there and get RDFa adopted, 
at which point it will hopefully seem a much more useful proposition for 
inclusion in HTML5.

In the short term the RDFa community can presumably provide a 
specialized "HTML5 + RDFa" validator for adopters to use until RDFa is 
incorporated into the core spec and tools.

It would seem that it's much easier to get into the spec when your 
feature is proven to be useful by real-world adoption.



[1] canvas, keygen, frames and script are examples of this phenomenon.



From bzbarsky at MIT.EDU  Sun Jan 11 18:41:58 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Sun, 11 Jan 2009 21:41:58 -0500
Subject: [whatwg] Content type sniffing
Message-ID: <496AADF6.1060607@mit.edu>

I just noticed that section 2.7.1 of HTML5 says:

   Extensions must not be used for determining resource types
   for resources fetched over HTTP.

While I understand the reasons for this, there are certainly cases where 
this will break sites (basically those using HTTP 0.9, or later HTTP 
versions but not sending a content-type).  In particular, the HTML 
sniffing in the algorithm is very limited and wouldn't sniff this document:

   <body>Some text</body>

as HTML.

Now this use case (no content-type at all) was pretty common when the 
unknown type sniffer in Gecko was written, but that was years ago.  Do 
we have any data on how common it is now?

-Boris

P.S.  Of course at the moment the sniffer in Gecko is used for more than 
just HTTP, and it looks like we'll need separate modes for things like 
HTTP and things like file://.  I can live with that, though.  For the 
file:// case detection of HTML in documents with no 
doctype/<html>/<head> is a must.


From alex.baldacchino at email.it  Sun Jan 11 19:22:28 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Mon, 12 Jan 2009 04:22:28 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
Message-ID: <496AB774.2040500@email.it>

Toby A Inkster ha scritto:
> Calogero Alex Baldacchino wrote:
>
>> The concern is about every kind of metadata with respect to their
>> possible uses; but, while it's been stated that Microforamts (for
>> instance) don't require any purticular support by UAs (thus they're
>> backward compatible), RDFa would be a completely new feature, thus html5
>> specification should say what UAs are espected to do with such new
>> attributes.
>
> RDFa doesn't require any special support beyond the special support 
> that is required for Microformats. i.e. nothing. User agents are free 
> to ignore the RDFa attributes. In that sense, RDFa already "works" in 
> pretty much every existing browser, even going back to dinosaurs like 
> Mosaic and UdiWWW.
>
> Agents are of course free to offer more than that. Look at what they 
> do with Microformats: Firefox for instance offers an API to handle 
> Microformats embedded on a page; Internet Explorer offers its "Web 
> Slices" feature.
>

Well, at the beginning of this thread the possible need to interchange 
RDF metadata and merge triples from different vocabularies was suggested 
as a use case for RDFa serialization of RDF, and this would hint a 
requirement for supporting an  RDFa processor in every conforming UA. 
This also opens a question about what else might be needed beside 
collecting triples (is an API to build custom query applications enough, 
or should some query feature be provided by browsers? are there possible 
problems involved (like possible spam through fake metadata in cached 
ads)? possible solutions to prevent or moderate it?).

If, otherwise, nothing special must be done by browsers with RDFa 
attributes, and instead their main use is for script or plugin or 
server-side computations, or for "free" support by UA, these ones would 
be no way different from any other kind of custom attributes (thus 
should a validation requirement be let's accept every attribute?), 
herein included data-*, but for the /intended use/, which may make the 
difference but is something only a human can understand, and no 
validator can check (from this point of view, validating RDFa 
attributes, whatever else attribute, or just html5 attributes and custom 
data-* ones would be the same, as validating would not be a concern as 
it isn't for proprietary CSS extensions).

>> For what concerns html serialization, in particular, I'd consider 
>> some code like [...] which is rendered properly
>
>
> Is it though? Try adding the following CSS:
>
>     span[property="cal:summary"] { font-weight: bold; }
>
> And you'll see that CSS doesn't cope with a missing ending tag in that 
> situation either.
>
> If you miss out a non-optional end tag, then funny things will happen 
> - RDFa isn't immune to that problem, but neither is the DOM model, 
> CSS, microformats, or anything else that relies on knowing where 
> elements end. A better comparison would be a missing </p> tag, which 
> is actually allowed in HTML, and HTML-aware RDFa processors can 
> generally handle just fine.

That's definetely *not* the same issue. As I've replied in a previous 
mail, people *do not* need proper styling to understend prose, they just 
need to understand the prose language, then their /brains/ will cope 
with the rest, thus the above example results in some acceptable 
graceful degradation (it may or may not be the wanted presentation, 
depending on where the closing </span> was to be positioned (it wouldn't 
be the right presentation in this case), but it is not too harmful 
anyway). Bots based on metadata, instead *do need* reliable metadata to 
work properly, unless they're made smart enough to debug the code 
they're fed (should Artificial Intelligence be a requirement? - no 
sarcasm here).

If broken/wrong presentation caused by a missing end tag had ever been 
an issue, html-serialization would have been deprecated in favour of 
xml-one (if something really "problematic" happened, authors would 
notice it on their very first test by opening a page in a browser, 
whereas an extensive and complete debug for triples might be an odd 
problem in a large document). In contrast with that, any break in 
metadata semantics caused by html-serialization can only be a sever 
issue for a metadata-based bot (because it needs accurate metadata, 
while a non-very-accurate presentation is not a great concern for human 
beings in most cases, and if no particular presentation is attached to 
those spans, but instead they're used just to add semantics through 
metadata, as it happens to embedd RDF through RDFa attributes, a 
side-effect may arise), thus html-serialization may be more prone to 
side-effects than xml-serialization (which stops on validation errors, 
being in turn a possible cause for side-effects with metadata), from 
this point of view -- that is, since RDFa semantics is more reliable in 
a more well-formed document, xml-serialization might help to debug some 
errors, while it is not a strict requirement for content presentation, 
and instead finding more or less emboldened words is better for users 
than finding a page which is not rendered at all, thus the differences 
between xhtml and html.

But if it's or will be agreed that inaccurate metadata are reliable, or 
that uncertain reliablility is not an issue for wide-scale semantic web 
applications, well, I really don't know what to say apart than I just 
have a different opinion.

However, that was just the first example I was able to produce just to 
give an idea; better examples can surely be thought out. What if, for 
instance, foster parenting or adoption agency caused metadata to be put 
far from (part of) their correspondent data? Style is inherited, but a 
wrong triple is a wrong triple (from this perspective, a parse error 
/might/ highlight some misplaced metadata more quickly than a raw debug 
of triples).

My point is that html-serialization is enough robust with respect to 
presentational issues, in most cases (it's the same for non-screen 
media), but it might not be the same for RDFa modelled metadata, which 
require a greater "well-formedness" than content presentation to be 
enough reliable, since RDFa is conceived with the purpose to allow RDF 
serialization into xml documents in first place, without the possible 
validation problems arising by direct use of xml-serialized RDF, and as 
an alternative to RELAX NG (since strict xml parsers, as for xhtml, are 
more diffused) -- it's in the first chapter of RDFa specification: 
"1.Motivation".

That is, RDFa is born as an xml-related feature in primis, thus I think 
that concerning whether it can work as well in another kind of document 
(not if it may work, but if it may work as well in different documents 
or if it can work better in some than in other ones) is legitimate -- of 
course the same concern may apply to eRDF as well as to other kinds of 
metadata.

>
>> considering RDFa relies on namespaces (thus,
>> adding RDFa attributes to HTML5 spec would require some features from
>> xml extensibility to be added to html serialization).
>
>
> RDFa *does not* rely on XML namespaces. RDFa relies on eight 
> attributes: about, rel, rev, property, datatype, content, resource and 
> typeof. It also relies on a CURIE prefix binding mechanism. In XHTML 
> and SVG, RDFa happens to use XML namespaces as this mechanism, because 
> they already existed and they were convenient. In non-XML markup 
> languages, the route to define CURIE prefixes is still to be decided, 
> though discussions tend to be leaning towards something like:
>
> <html prefix="dc=http://purl.org/dc/terms/ 
> foaf=http://xmlns.com/foaf/0.1/">
> <address rel="foaf:maker" rev="foaf:made">This document was made by <a 
> href="http://joe.example.com" typeof="foaf:Person" rel="foaf:homepage" 
> property="foaf:name">Joe Bloggs</a>.</address>
> </html>
>

Well, yes, that's a possible solution to be considered. Anyway, that 
would require (at least) another new attribute to be specc'ed out, with 
possible new concerns. For instance, a missing space between prefix/URI 
pairs might compromise its good parsing (while space separated curies, 
for instance, being shorter than absolute URIs, can focus a major 
attention on typing errors in hand-written code, but this is a 
subtlety), thus a separate attribute for each URI might be more robust 
(for instance something like xmlns-* or just ns-* in the <html> tag, 
similar to xmlns:* but not clashing with xml namespace mechanism, on the 
same line as data-* but with a different "scope"). Also, something like 
the eRDF use of <link> elements to declare namespaces (or mappings from 
prefixes to curies, to be more consistent with RDFa conventions) inside 
the head element might work, because an html document is likely to 
present such declarations once at the beginning. However, each solution 
would have its own "pros" and "cons", wile xml namespaces perfectly fit 
the purpose, even because (one of) their main use is to represent 
prefixed attributes or elements names taken from an RDF vocabulary which 
is in turn an XML 'format' and to embed them in another kind of 
document, that is to represent something coming from a different namespace.

> This discussion seems to be about "should/can RDFa work in HTML5?" 
> when in fact, RDFa already can and does work in HTML5 - there are 
> approaching a dozen interoperable implementations of RDFa, the 
> majority of which seem to handle non-XHTML HTML. Assuming that people 
> see value in RDFa, and assuming that the same people see value in 
> using HTML5, then these people will use RDFa in HTML5. The question we 
> should be discussing is not "should it work?" (because it already 
> does), but rather, "should it validate?"
>

There should be also people seeing value in eRDF, at least enough people 
for eRDF being supported by SearchMonkey. It is sure that these people 
see value in using eRDF within html documents, since eRDF is conceived 
to work with HTML "natively", that is without any need to change HTML 
(by introducing new attributes or using unrecognized ones); 
nevertheless, eRDF can't be valid HTML5 because of the "profile" 
attribute, which has been dropped. Should eRDF validate instead? Should 
we prefere eRDF to RDFa or viceversa? Should we treat them the very same 
way? Or should we just wait and see which one works better for people, 
to avoid an early specification of something later possibly 
demonstrating to be less useful than originally thought, for instance 
because most people decided to use something else?

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Con Danone Activia, puoi vincere cellulari Nokia e Macbook Air. Scopri come
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8551&d=12-1


From ian at hixie.ch  Sun Jan 11 19:37:11 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Jan 2009 03:37:11 +0000 (UTC)
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
Message-ID: <Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>

On Sun, 11 Jan 2009, Toby A Inkster wrote:
> 
> RDFa doesn't require any special support beyond the special support that 
> is required for Microformats. i.e. nothing. User agents are free to 
> ignore the RDFa attributes. In that sense, RDFa already "works" in 
> pretty much every existing browser, even going back to dinosaurs like 
> Mosaic and UdiWWW.

Is this true? One of the problems I thought we were trying to solve was 
that browsers were dumb, and the idea was that we wanted to enable 
browsers to take free-form questions from the user and answer them. It 
seems to me that if the browser doesn't have any special support, then 
this use case is not met.


> The question we should be discussing is not "should it work?" (because 
> it already does), but rather, "should it validate?"

No, the question is "what problem are we solving?". Talking about RDFa, 
RDF, eRDF, Microformats, and so forth doesn't answer this question.

The question "should it validate" is the question "do we want to solve the 
problem and is this the right solution", which is a question we can't 
answer without actually knowing what the problem is.

So far, all I really know is that the problem is apparently obvious.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From mart at degeneration.co.uk  Sun Jan 11 19:50:19 2009
From: mart at degeneration.co.uk (Martin Atkins)
Date: Sun, 11 Jan 2009 19:50:19 -0800
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
	<Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>
Message-ID: <496ABDFB.4010609@degeneration.co.uk>

Ian Hickson wrote:
> 
>> The question we should be discussing is not "should it work?" (because 
>> it already does), but rather, "should it validate?"
> 
> No, the question is "what problem are we solving?". Talking about RDFa, 
> RDF, eRDF, Microformats, and so forth doesn't answer this question.
> 
> The question "should it validate" is the question "do we want to solve the 
> problem and is this the right solution", which is a question we can't 
> answer without actually knowing what the problem is.
> 
> So far, all I really know is that the problem is apparently obvious.
> 

My understanding of the use-case, based on discussions so far, is:

- Allow authors to embed annotations in HTML documents such that RDF 
triples can be unambiguously extracted from human-readable data without 
duplicating the data, and thus ensuring that the machine-readable data 
and the human-readable data remain in sync.

The disconnect you're facing is that the proposers of RDFa consider the 
ability to encode RDF triples to be a goal, while you consider RDF 
triples to be a solution to a (as-yet-undetermined) higher-level 
problem. They take RDF as a given, while you do not. They have already 
solved some problems with RDF and wish only to adapt this generalized 
solution to work in HTML, while you wish to re-solve all of these 
problems from the ground up.

Would you agree with this analysis?

If this is accurate, then it's difficult to see how continued discussion 
on this topic can be productive.



From ian at hixie.ch  Sun Jan 11 20:20:32 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Jan 2009 04:20:32 +0000 (UTC)
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <496ABDFB.4010609@degeneration.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
	<Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>
	<496ABDFB.4010609@degeneration.co.uk>
Message-ID: <Pine.LNX.4.62.0901120411370.29785@hixie.dreamhostps.com>

On Sun, 11 Jan 2009, Martin Atkins wrote:
> 
> The disconnect you're facing is that the proposers of RDFa consider the 
> ability to encode RDF triples to be a goal, while you consider RDF 
> triples to be a solution to a (as-yet-undetermined) higher-level 
> problem. They take RDF as a given, while you do not.

Agreed.


> They have already solved some problems with RDF and wish only to adapt 
> this generalized solution to work in HTML, while you wish to re-solve 
> all of these problems from the ground up.

I don't necessarily wish to resolve the problems -- if they have existing 
good solutions, I'm all in favour of reusing them. I just want to know 
what those problems are that we're solving, so that we can make sure that 
the solutions we're adopting are in fact solving the problems we want to 
solve. It would be irresponsible to add features without knowing why.


> If this is accurate, then it's difficult to see how continued discussion 
> on this topic can be productive.

Well presumably if the RDF and RDFa communities have already solved some 
problems, it will be possible for them to tell us what those problems are.

That's all I'm asking for.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From chaals at opera.com  Sun Jan 11 21:19:10 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Mon, 12 Jan 2009 16:19:10 +1100
Subject: [whatwg] What RDF does Re:  Trying to work out...
In-Reply-To: <4966AE40.3040600@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
Message-ID: <op.unmo18akwxe0ny@c211-28-146-67.smelb2.vic.optusnet.com.au>

On Fri, 09 Jan 2009 12:54:08 +1100, Calogero Alex Baldacchino  
<alex.baldacchino at email.it> wrote:

> I admit I'm not very expert in RDF use, thus I have a few questions.  
> Specifically, maybe I can guess the advantages when using the same  
> (carefully modelled, and well-known) vocabulary/ies; but when two  
> organizations develop their own vocabularies, similar yet different, to  
> model the same kind of informations, is merging of data enough? Can a  
> processor give more than a collection of triples, to be then interpreted  
> basing on knowledge on the used vocabulary/ies?

RDF consists of several parts. One of the key parts explains how to make  
an RDF vocabulary self-describing in terms of other vocabularies.

>  I mean, I assume my tools can extract RDF(a) data from whatever  
> document, but my query interface is based on my own vocabulary: when I  
> merge informations from an external vocabulary, do I need to translate  
> one vocabulary to the other (or at least to modify the query backend, so  
> that certain curies are recognized as representing the same concepts -  
> e.g. to tell my software that 'foaf:name' and 'ex:someone' are  
> equivalent, for my purposes)? If so, merging data might be the minor  
> part of the work I need to do, with respect to non-RDF(a) metadata (that  
> is, I'd have tools to extract and merge data anyway, and once I  
> translated external metadata to my format, I could use my own tools to  
> merge data), specially if the same model is used both by mine and an  
> external organization (therefore requiring an easier translation).

If a vocabulary is described, then you can do an automated translation  
 from one RDF vocabulary to another by using your original query based in  
your original vocabulary. This is one of the strengths of RDF.

>  Thus, I'm thinking the most valuable benefit of using RDF/RDFa is the  
> sureness that both parties are using the very same data model, despite  
> the possible use of different vocabularies -- it seems to me that the  
> concept of triples consisting of a subject, a predicate and an object is  
> somehow similar to a many-to-many association in a database, whereas one  
> might prefer a one-to-many approach - though, the former might be a  
> natural choice to model data which are usually sparse, as in a document  
> prose.

I don't see the ananlogy, but yes, I think the big benefit is being able  
to ensure that you know the data model without knowing the vocabulary a  
priori - since this is sufficient to automate the process of merging data  
into your model.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From chaals at opera.com  Sun Jan 11 21:19:24 2009
From: chaals at opera.com (Charles McCathieNevile)
Date: Mon, 12 Jan 2009 16:19:24 +1100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <4967A856.5010206@gmx.de>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>
	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>
	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>
	<48B5D840.5000704@digitalbazaar.com>
	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>
	<op.um19y5ajwxe0ny@widsithpro.lan> <495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan> <4966AE40.3040600@email.it>
	<49673926.4020902@gmx.de>
	<dd0fbad0901091135j247e4b83xc56a12b14572ab55@mail.gmail.com>
	<4967A856.5010206@gmx.de>
Message-ID: <op.unmo2mwuwxe0ny@c211-28-146-67.smelb2.vic.optusnet.com.au>

On Sat, 10 Jan 2009 06:41:10 +1100, Julian Reschke <julian.reschke at gmx.de>  
wrote:

> 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 whether there's a problem
>> we need to solve, or how we should solve it.
>
> For the record: I disagree with that. I have the impression that no  
> matter how many problems are presented, the answer is going to be: "not  
> that stone -- fetch me another stone".

There does appear to be some of this. I have no idea if that is just an  
impression or the truth. Hence my continued following of the thread.

>> Alex's suggestion, while officially against spec, has the benefit of
>> allowing RDFa supporters to sort out their use cases through
>> experience.  That's the back door into the spec, after all; you don't
>
> If something that is against the spec is acceptable, then it's *much*  
> easier to just use the already defined attributes. Better breaking the  
> spec by using new attributes then abusing existing ones.

Indeed. I the data-* attributes had some reserved values, then one might  
expect people to invest in them on the scale that they have typically made  
RDF investments. But then there would be no need to change the attribute  
names at all (nor, for that matter, to put much effort into other  
attribute names following the design pattern. It just becomes another  
approach to namespaces with another centralisation process required). The  
question is what would convince the editors of the spec that there is in  
fact a use case for RDF in HTML which is what has led to the request to  
include RDFa (a form of RDF carefully designed to fit into HTML).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle fran?ais -- hablo espa?ol -- jeg l?rer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com


From mart at degeneration.co.uk  Sun Jan 11 21:23:04 2009
From: mart at degeneration.co.uk (Martin Atkins)
Date: Sun, 11 Jan 2009 21:23:04 -0800
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <Pine.LNX.4.62.0901120411370.29785@hixie.dreamhostps.com>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
	<Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>
	<496ABDFB.4010609@degeneration.co.uk>
	<Pine.LNX.4.62.0901120411370.29785@hixie.dreamhostps.com>
Message-ID: <496AD3B8.6070005@degeneration.co.uk>

Ian Hickson wrote:
> 
>> They have already solved some problems with RDF and wish only to adapt 
>> this generalized solution to work in HTML, while you wish to re-solve 
>> all of these problems from the ground up.
> 
> I don't necessarily wish to resolve the problems -- if they have existing 
> good solutions, I'm all in favour of reusing them. I just want to know 
> what those problems are that we're solving, so that we can make sure that 
> the solutions we're adopting are in fact solving the problems we want to 
> solve. It would be irresponsible to add features without knowing why.
> 

I would assume that our resident proponents are already satisfied that 
their higher-level problem have been solved, and this is why they're 
frustrated that you won't just let them map their existing solutions 
into HTML all in one fell swoop.

I'm not sure I'd put myself into the "RDF proponent" bucket, but I do 
know one use-case of RDF that I've encountered frequently so I'll post 
it as a starting point.

The FOAF schema for RDF[0] addresses the problem of making personal 
profile data machine-readable along with some of the relationships 
between people. From the outside looking in, it seems that the goal they 
set themselves was to make machine-readable the sort of information you 
find on a social networking site.

One problem this can solve is that an agent can, given a URL that 
represents a person, extract some basic profile information such as the 
person's name along with references to other people that person knows. 
This can further be applied to allow a user who provides his own URL 
(for example, by signing in via OpenID) to bootstrap his account from 
existing published data rather than having to re-enter it.

Google Social Graph API[1] apparently makes use of FOAF (when serialized 
as XML) as one of the sources of data so that given a URL that 
represents a person it can return a list of URLs that represent friends 
of that person.

The Google Profiles application[2] makes use of the output of the Social 
Graph API to suggest URLs that a user might want to list on his profile 
page, so the user only needs to fill in a couple of URLs by hand.

So, to distill that into a list of requirements:

- Allow software agents to extract profile information for a person as 
often exposed on social networking sites from a page that "represents" 
that person.

   There is a number of existing solutions for this:
     * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc
     * The vCard format
     * The hCard microformat
     * The PortableContacts protocol[3]
     * Natural Language Processing of HTML documents

- Allow software agents to determine who a person lists as their friends 
given a page that "represents" that person.

   Again, there are competing solutions:
     * FOAF in RDF serialized as XML, Turtle, RDFa, eRDF, etc
     * The XFN microformat[4]
     * The PortableContacts protocol[3]
     * Natural Language Processing of HTML documents

-----------------------------------------------

Assuming that the above is a convincing problem domain, now let's add in 
the following requirement:

- Allow the above to be encoded without duplicating the data in both 
machine-readable and human-readable forms.

Now our solution list is reduced to (assuming we consider both 
requirements together):
     * FOAF in RDF serialized as RDFa or eRDF
     * The hCard microformat + the XFN microformat
     * Natural Language Processing of HTML documents

All three of the above options address the use-cases as I stated them -- 
the Social Graph API apparently uses all three if you're willing to 
consider a MySpace-specific "screen-scraper" as Natural Language 
Processing -- so what would be the advantages of the first solution?

  * Existing RDF-based systems can use an off-the-shelf RDFa or eRDF 
parser and get the same data model (RDF triples of FOAF predicates) that 
they were already getting from the XML and Turtle RDF serializations, 
reducing the amount of additional work that must be done to consume this 
format.

  * FOAF has an extensive vocabulary that's based on fields that have 
been observed on social networking sites, while hCard is built on vCard 
which has a more constrained scope intended for the sort of entries 
you'd expect to find in an "address book".

  * FOAF has been adopted -- usually in the RDF-XML serialization -- by 
some number of social networking sites (e.g. LiveJournal) so they are 
presumably already somewhat familiar with the FOAF vocabulary and may 
therefore be able to adopt it more easily in the RDFa or eRDF 
serializations.

Though there are of course also some disadvantages:

  * Some sites are already publishing XFN and/or hCard so consuming 
software would need to continue to support these in addition to 
FOAF-in-HTML-somehow, which is more work than supporting only XFN and 
hCard. (In other words, "XFN/hCard already work today")

  * RDFa requires extensions to the HTML language, while XFN, hCard and 
NLP do not.

  * Many existing FOAF parsers are not actually RDF parsers but are 
rather using stock XML parsers and assuming a particular tree layout, so 
they would not be able to reuse any code in processing triples from RDFa 
or eRDF.

-------------------------------------

Is this the sort of thing you're looking for, Ian?

Much of the above section could be applied to any other RDF vocabulary 
with a bit of search and replace, but I'll leave that to others since 
FOAF is the only RDF vocabulary with which I have any experience.

(and if I've misrepresented any of the facts about FOAF or RDF I'm happy 
to be corrected. I'm writing this only in an attempt to move the 
discussion forward; I'm currently neutral on whether RDFa should be 
adopted into HTML5.)

[0]http://www.foaf-project.org/
[1]http://code.google.com/apis/socialgraph/
[2]http://www.google.com/support/accounts/bin/answer.py?answer=97703&hl=en
[3]http://portablecontacts.net/
[4]http://www.gmpg.org/xfn/



From ian at hixie.ch  Sun Jan 11 22:09:51 2009
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Jan 2009 06:09:51 +0000 (UTC)
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <496AD3B8.6070005@degeneration.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
	<Pine.LNX.4.62.0901120333110.29785@hixie.dreamhostps.com>
	<496ABDFB.4010609@degeneration.co.uk>
	<Pine.LNX.4.62.0901120411370.29785@hixie.dreamhostps.com>
	<496AD3B8.6070005@degeneration.co.uk>
Message-ID: <Pine.LNX.4.62.0901120556160.29785@hixie.dreamhostps.com>

On Sun, 11 Jan 2009, Martin Atkins wrote:
> 
> One problem this can solve is that an agent can, given a URL that 
> represents a person, extract some basic profile information such as the 
> person's name along with references to other people that person knows. 
> This can further be applied to allow a user who provides his own URL 
> (for example, by signing in via OpenID) to bootstrap his account from 
> existing published data rather than having to re-enter it.
> 
> So, to distill that into a list of requirements:
> 
> - Allow software agents to extract profile information for a person as often
> exposed on social networking sites from a page that "represents" that person.
> 
> - Allow software agents to determine who a person lists as their friends 
> given a page that "represents" that person.
>
> - Allow the above to be encoded without duplicating the data in both 
> machine-readable and human-readable forms.
> 
> Is this the sort of thing you're looking for, Ian?

Yes, the above is perfect. (I cut out the bits that weren't really "the 
problem" from the quote above -- the above is what I'm looking for.)

The most critical part is "allow a user who provides his own URL to 
bootstrap his account from existing published data rather than having to 
re-enter it". The one thing I would add would be a scenario that one would 
like to be able to play out, so that we can see if our solution would 
enable that scenario.

For example:

   "I have an account on social networking site A. I go to a new social 
   networking site B. I want to be able to automatically add all my 
   friends from site A to site B."

There are presumably other requirements, e.g. "site B must not ask the 
user for the user's credentials for site A" (since that would train people 
to be susceptible to phishing attacks). Also, "site A must not publish the 
data in a manner that allows unrelated users to obtain privacy-sensitive 
data about the user", for example we don't want to let other users 
determine relationships that the user has intentionally kept secret [1].

It's important that we have these scenarios so that we can check if the 
solutions we consider are actually able to solve these problems, these 
scenarios, within the constraints and requirements we have.

[1] http://w2spconf.com/2008/papers/s3p2.pdf

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From whatwg at adambarth.com  Sun Jan 11 23:54:18 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Sun, 11 Jan 2009 23:54:18 -0800
Subject: [whatwg] Content type sniffing
In-Reply-To: <496AADF6.1060607@mit.edu>
References: <496AADF6.1060607@mit.edu>
Message-ID: <7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>

On Sun, Jan 11, 2009 at 6:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I just noticed that section 2.7.1 of HTML5 says:
>
>  Extensions must not be used for determining resource types
>  for resources fetched over HTTP.

Extensions are bad news for content sniffing because they can often be
chosen by the attacker.  For example, suppose user-uploaded content is
can be downloaded at:

http://example.com/download.php

In most PHP configurations, the attacker can choose whatever file
extension he likes by directing the user's browser to:

http://example.com/download.php/whatever.foo

And the PHP script will happily run.

> Now this use case (no content-type at all) was pretty common when the
> unknown type sniffer in Gecko was written, but that was years ago.  Do we
> have any data on how common it is now?

Yes.  We do have lots of data from opt-in user metrics from Chrome.
Here is a somewhat recent summary:

https://crypto.stanford.edu/~abarth/research/html5/content-sniffing/

To address your particular concern, <body occurs 6899 times less often
than <script on Web content that lacks a Content-Type (or has an bogus
Content-Type like */*), assuming I did my arithmetic correctly.

> P.S.  Of course at the moment the sniffer in Gecko is used for more than
> just HTTP, and it looks like we'll need separate modes for things like HTTP
> and things like file://.  I can live with that, though.  For the file://
> case detection of HTML in documents with no doctype/<html>/<head> is a must.

I'm sympathetic to adding more HTML tags to the list, but I'm not sure
how far down the tail we should go.  In Chrome, we went for 99.999%
compatibility, which might be a bit far down the tail.  You can see
the algorithm here:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_sniffer.cc?view=markup

Using that figure, we went down to <p (which is two tags less common
than <body).

Adam


From whatwg at adambarth.com  Mon Jan 12 00:02:31 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 12 Jan 2009 00:02:31 -0800
Subject: [whatwg] Content type sniffing
In-Reply-To: <7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>
References: <496AADF6.1060607@mit.edu>
	<7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>
Message-ID: <7789133a0901120002v38d7012fg55dd145b9d39f4ca@mail.gmail.com>

I should say that these figures are weighted by the number of page
loads, so if sniffing for a particular tag is needed for the digg.com
home page, it will show up as a large number.  If you don't weight by
traffic, you get similar results, but with slightly different numbers.

Adam


On Sun, Jan 11, 2009 at 11:54 PM, Adam Barth <whatwg at adambarth.com> wrote:
> On Sun, Jan 11, 2009 at 6:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> I just noticed that section 2.7.1 of HTML5 says:
>>
>>  Extensions must not be used for determining resource types
>>  for resources fetched over HTTP.
>
> Extensions are bad news for content sniffing because they can often be
> chosen by the attacker.  For example, suppose user-uploaded content is
> can be downloaded at:
>
> http://example.com/download.php
>
> In most PHP configurations, the attacker can choose whatever file
> extension he likes by directing the user's browser to:
>
> http://example.com/download.php/whatever.foo
>
> And the PHP script will happily run.
>
>> Now this use case (no content-type at all) was pretty common when the
>> unknown type sniffer in Gecko was written, but that was years ago.  Do we
>> have any data on how common it is now?
>
> Yes.  We do have lots of data from opt-in user metrics from Chrome.
> Here is a somewhat recent summary:
>
> https://crypto.stanford.edu/~abarth/research/html5/content-sniffing/
>
> To address your particular concern, <body occurs 6899 times less often
> than <script on Web content that lacks a Content-Type (or has an bogus
> Content-Type like */*), assuming I did my arithmetic correctly.
>
>> P.S.  Of course at the moment the sniffer in Gecko is used for more than
>> just HTTP, and it looks like we'll need separate modes for things like HTTP
>> and things like file://.  I can live with that, though.  For the file://
>> case detection of HTML in documents with no doctype/<html>/<head> is a must.
>
> I'm sympathetic to adding more HTML tags to the list, but I'm not sure
> how far down the tail we should go.  In Chrome, we went for 99.999%
> compatibility, which might be a bit far down the tail.  You can see
> the algorithm here:
>
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_sniffer.cc?view=markup
>
> Using that figure, we went down to <p (which is two tags less common
> than <body).
>
> Adam
>


From julian.reschke at gmx.de  Mon Jan 12 00:14:34 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 12 Jan 2009 09:14:34 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <496A8EC2.7070403@degeneration.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
	<496A8EC2.7070403@degeneration.co.uk>
Message-ID: <496AFBEA.7020400@gmx.de>

Martin Atkins wrote:
> ...
> If it is true that RDFa can work today with no ill-effect in downlevel 
> user-agents, what's currently blocking its implementation? Concern for 
> validation?
> 
> It seems to me that many HTML extensions are implemented first and 
> specified later[1], so perhaps it would be in the interests of RDFa 
> proponents to get some implementations out there and get RDFa adopted, 
> at which point it will hopefully seem a much more useful proposition for 
> inclusion in HTML5.
> 
> In the short term the RDFa community can presumably provide a 
> specialized "HTML5 + RDFa" validator for adopters to use until RDFa is 
> incorporated into the core spec and tools.
> 
> It would seem that it's much easier to get into the spec when your 
> feature is proven to be useful by real-world adoption.
> ...

What he said.

Although I *do* believe that in the end we'll want RDFa-in-HTML5, what's 
really important right now is *not* RDFa-in-HTML5 but RDFa-in-HTML4. 
Define that, make it a success, and the rest will be simple.

Best regards, Julian


From jgraham at opera.com  Mon Jan 12 01:19:55 2009
From: jgraham at opera.com (James Graham)
Date: Mon, 12 Jan 2009 10:19:55 +0100
Subject: [whatwg] data-* [Was:Re: Trying to work out the problems solved by
 RDFa]
In-Reply-To: <496A28D6.90104@googlemail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>	<49695EA4.1060302@email.it>
	<4969BED3.9010401@googlemail.com>	<496A23D8.9090901@email.it>
	<496A28D6.90104@googlemail.com>
Message-ID: <496B0B3B.8090507@opera.com>

Benjamin Hawkes-Lewis wrote:
> On 11/1/09 16:52, Calogero Alex Baldacchino wrote:
> 
>> Well, that's a chance, of course, but that's *not* RDFa as specified by
>> W3C; for instance, @property is specified as accepting _only_ CURIEs
> 
> Good point; I hadn't spotted that.
> 
>> It's the same with every possible existing custom (non-standard)
>> attributes and elements out there, since there is no standard for them,
>> and instead data-* has been created;
> 
> Emphatically, data-* has been created for private use data encoding 
> (basically for scripting purposes) not as a replacement for the existing 
> practices of adding new elements and attributes to HTML without going 
> through W3C/WHATWG.

It should, perhaps set alarm bells ringing that almost every time data-* 
attributes come up, people suggest using them to publish data to the web 
at large rather than as internal scripting hooks. Since the restrictions 
on data-* are not machine checkable, even the majority of "standards 
aware" authors are unlikely to heed them. Therefore the net effect of 
the restriction will be to prevent conscientious standards bodies from 
using data-* attributes in their specifications. It is quite possible 
that popular technologies will arise from sources other than such 
standards organisations and so use of data-* for more than just private 
scripting may be inevitable.

It is also possible that features that start off as private scripting 
hooks will evolve into data publishing features. This again would lead 
to the natural breaking of the restriction of data-* attributes.

(I know I have said this before but I forget whether I posted it or just 
discussed it on IRC.)



From julian.reschke at gmx.de  Mon Jan 12 01:54:52 2009
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 12 Jan 2009 10:54:52 +0100
Subject: [whatwg] data-* [Was:Re: Trying to work out the problems solved
 by RDFa]
In-Reply-To: <496B0B3B.8090507@opera.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>	<49695EA4.1060302@email.it>	<4969BED3.9010401@googlemail.com>	<496A23D8.9090901@email.it>	<496A28D6.90104@googlemail.com>
	<496B0B3B.8090507@opera.com>
Message-ID: <496B136C.8070003@gmx.de>

James Graham wrote:
> It should, perhaps set alarm bells ringing that almost every time data-* 
> attributes come up, people suggest using them to publish data to the web 
> at large rather than as internal scripting hooks. Since the restrictions 
> on data-* are not machine checkable, even the majority of "standards 
> aware" authors are unlikely to heed them. Therefore the net effect of 
> the restriction will be to prevent conscientious standards bodies from 
> using data-* attributes in their specifications. It is quite possible 
> that popular technologies will arise from sources other than such 
> standards organisations and so use of data-* for more than just private 
> scripting may be inevitable.
> 
> It is also possible that features that start off as private scripting 
> hooks will evolve into data publishing features. This again would lead 
> to the natural breaking of the restriction of data-* attributes.
> 
> (I know I have said this before but I forget whether I posted it or just 
> discussed it on IRC.)

Agreed.

So what does this tell us about the point of view that distributed 
extensibility should not be supported by HTML5?

Best regards, Julian





From stewart.brodie at antplc.com  Mon Jan 12 06:25:33 2009
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Mon, 12 Jan 2009 14:25:33 +0000
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com> 
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com>
Message-ID: <2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost>

Ian Hickson <ian at hixie.ch> wrote (on 25 July 2008):

> I've made [getElementsByClassName] consistent with how classes work in CSS
> (case-insensitive for quirks and case-sensitive otherwise).

I was looking for some tests for this API and found some from Opera (found
at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the
dates on them predate the latest spec changes (which causes some to fail
now), I was wondering if up to date versions are now kept somewhere else
instead?

-- 
Stewart Brodie
Software Engineer
ANT Software Limited


From mail at tobyinkster.co.uk  Mon Jan 12 07:33:45 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Mon, 12 Jan 2009 15:33:45 +0000
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Message-ID: <D200A4FA-2DE6-429E-8377-F5090D5C5116@tobyinkster.co.uk>

Martin Atkins wrote:

>   * Some sites are already publishing XFN and/or hCard so consuming
> software would need to continue to support these in addition to
> FOAF-in-HTML-somehow, which is more work than supporting only XFN and
> hCard.

Mitigating this though is GRDDL which allows the hCard+XFN to be  
parsed using a subset of FOAF (e.g. http://weborganics.co.uk/hFoaF/)  
and thus merged with FOAF available as RDF/XML, RDFa, etc.

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





From bzbarsky at MIT.EDU  Mon Jan 12 07:54:15 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Jan 2009 10:54:15 -0500
Subject: [whatwg] Content type sniffing
In-Reply-To: <7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>
References: <496AADF6.1060607@mit.edu>
	<7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>
Message-ID: <496B67A7.7070809@mit.edu>

Adam Barth wrote:
> Extensions are bad news for content sniffing because they can often be
> chosen by the attacker.  For example, suppose user-uploaded content is
> can be downloaded at:
> 
> http://example.com/download.php
> 
> In most PHP configurations, the attacker can choose whatever file
> extension he likes by directing the user's browser to:
> 
> http://example.com/download.php/whatever.foo
> 
> And the PHP script will happily run.

Right, I understand that.

> Yes.  We do have lots of data from opt-in user metrics from Chrome.
> Here is a somewhat recent summary:
> 
> https://crypto.stanford.edu/~abarth/research/html5/content-sniffing/

I'm not quite sure what to make of this, actually.  Specifically, where 
is the "22.19%" number for "HTML Tags" coming from?  22.19% of what? 
The magic numbers stuff actually adds up to 100%, but of what?

> To address your particular concern, <body occurs 6899 times less often
> than <script on Web content that lacks a Content-Type (or has an bogus
> Content-Type like */*), assuming I did my arithmetic correctly.

OK, that's good to know.

> I'm sympathetic to adding more HTML tags to the list, but I'm not sure
> how far down the tail we should go.  In Chrome, we went for 99.999%
> compatibility, which might be a bit far down the tail.

Doesn't seem that way to me, given the number of web pages out there.

> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_sniffer.cc?view=markup

Ah, ok.  The relevant Gecko code is 
<http://hg.mozilla.org/mozilla-central/annotate/9f82199fdb9c/netwerk/streamconv/converters/nsUnknownDecoder.cpp#l477>. 
I'd probably be fine with trimming that list down a bit, but I'm not 
quite sure what the downsides of having more tags in it are here.

-Boris


From whatwg at adambarth.com  Mon Jan 12 09:12:31 2009
From: whatwg at adambarth.com (Adam Barth)
Date: Mon, 12 Jan 2009 09:12:31 -0800
Subject: [whatwg] Content type sniffing
In-Reply-To: <496B67A7.7070809@mit.edu>
References: <496AADF6.1060607@mit.edu>
	<7789133a0901112354r4aabdb74teb4a534e3fc7240b@mail.gmail.com>
	<496B67A7.7070809@mit.edu>
Message-ID: <7789133a0901120912jda5a8bfp9dd1447f38bcf8c@mail.gmail.com>

On Mon, Jan 12, 2009 at 7:54 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I'm not quite sure what to make of this, actually.  Specifically, where is
> the "22.19%" number for "HTML Tags" coming from?  22.19% of what? The magic
> numbers stuff actually adds up to 100%, but of what?

Sorry, the % was confusing.  I've removed them.  These table are the
relative frequency with which those rules fire in the content sniffer.
 Probably should have scaled them all to be out of 100 or out of 1,
but it was more convenient to scale them out of the totals that I did.

>> I'm sympathetic to adding more HTML tags to the list, but I'm not sure
>> how far down the tail we should go.  In Chrome, we went for 99.999%
>> compatibility, which might be a bit far down the tail.
>
> Doesn't seem that way to me, given the number of web pages out there.

I don't think it makes sense to compare that percentage to the number
of web pages.  Instead, imagine a user who views 100 pages a day.
That user will, in a crude "average" sense, come across a broken web
page once every three years.

>> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/mime_sniffer.cc?view=markup
>
> Ah, ok.  The relevant Gecko code is
> <http://hg.mozilla.org/mozilla-central/annotate/9f82199fdb9c/netwerk/streamconv/converters/nsUnknownDecoder.cpp#l477>.

Yes, I've examined that code in detail.  :)  Here is a web page that
will let you compare the sniffing algorithms used by four popular
browsers:

http://webblaze.cs.berkeley.edu/2009/content-sniffing/

> I'd probably be fine with trimming that list down a bit, but I'm not quite
> sure what the downsides of having more tags in it are here.

Most of the cost is complexity (which leads to security
vulnerabilities).  People who let users upload content and who build
firewalls that filter content at the application layer (for example,
to look for malware) need to understand browser content sniffing
algorithms in order to build secure products.  There is a huge
complexity win for standardizing the algorithm across multiple
implementations, and there is a small complexity loss for each
sniffing heuristic we add.

One plan for going forward is to resolve
https://bugzilla.mozilla.org/show_bug.cgi?id=465007 and then open
another bug for harmonizing the HTML heuristic (with the expectation
that harmonization will probably involve changing both the spec and
the implementation).

Adam


From hsivonen at iki.fi  Mon Jan 12 11:29:27 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 12 Jan 2009 21:29:27 +0200
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
References: <A7FCAE13-E943-448C-978E-CB0D6C23A502@tobyinkster.co.uk>
Message-ID: <3B46B51E-971C-415A-A380-93E78A0877B9@iki.fi>

On Jan 11, 2009, at 14:01, Toby A Inkster wrote:

> RDFa *does not* rely on XML namespaces. RDFa relies on eight  
> attributes: about, rel, rev, property, datatype, content, resource  
> and typeof. It also relies on a CURIE prefix binding mechanism. In  
> XHTML and SVG, RDFa happens to use XML namespaces as this mechanism,  
> because they already existed and they were convenient.

Convenience is debatable. In any case, it is rather disingenuous to  
say that RDFa doesn't rely on XML Namespaces when all that has been  
defined so far relies of attributes whose qname contains the substring  
"xmlns".

> In non-XML markup languages, the route to define CURIE prefixes is  
> still to be decided, though discussions tend to be leaning towards  
> something like:
>
> <html prefix="dc=http://purl.org/dc/terms/ foaf=http://xmlns.com/foaf/0.1/ 
> ">
> <address rel="foaf:maker" rev="foaf:made">This document was made by  
> <a href="http://joe.example.com" typeof="foaf:Person"  
> rel="foaf:homepage" property="foaf:name">Joe Bloggs</a>.</address>
> </html>

Unless this syntax were also used for XHTML, the above would be in  
violation of the DOM Consistency Design Principle of the W3C HTML WG.

> This discussion seems to be about "should/can RDFa work in HTML5?"  
> when in fact, RDFa already can and does work in HTML5 - there are  
> approaching a dozen interoperable implementations of RDFa, the  
> majority of which seem to handle non-XHTML HTML.

Those implementations violate the software implementation reuse  
principle that motivates the DOM Consistency Design Principle. (The  
software reuse principle being that the same code path be used for  
both HTML and XHTML on layers higher than the parser.)

The prefix mapping mechanism of CURIEs has been designed with  
disregard towards this software reuse principle (in use in Gecko,  
WebKit and, I gather, Presto) that should have been known to anyone  
working on Web-related specs far before "DOM Consistency" was written  
into the Design Principles of the HTML WG.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From hsivonen at iki.fi  Mon Jan 12 11:31:13 2009
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 12 Jan 2009 21:31:13 +0200
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <496A23D8.9090901@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it>
Message-ID: <EA65FF05-0A5D-4AD7-8D19-198010A281D4@iki.fi>

On Jan 11, 2009, at 18:52, Calogero Alex Baldacchino wrote:

> However, actually it's the same for RDFa attributes, because they're  
> not in the spec. From this point of view, introducing six new  
> attributes, or resorting to an older one is not very different, thus  
> (again) why RDFa and not eRDF?


eRDF is very different in not relying on attributes whose qname  
contains the substring "xmlns".

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/




From lists.whatwg at stakface.com  Mon Jan 12 12:10:41 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Mon, 12 Jan 2009 20:10:41 +0000
Subject: [whatwg] <code> in "in body" insertion mode (8.2.5)
Message-ID: <20090112201041.234DE14D86F@looneymail-mx2.g.dreamhost.com>

"code" is listed in the formatting category of elements, but isn't dealt with in the same way as other formatting elements when in the "in body" insertion mode. Currently it will fall through to the "any other start tag" case, so the note in that case that says "This element will be a phrasing element" is incorrect.

I'm assuming that the "code" element should be listed along with the other formatting elements (b, big, em, etc.) for the "in body" insertion mode. Is that correct?

kats


From alex.baldacchino at email.it  Mon Jan 12 12:26:48 2009
From: alex.baldacchino at email.it (Calogero Alex Baldacchino)
Date: Mon, 12 Jan 2009 21:26:48 +0100
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <496A28D6.90104@googlemail.com>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it> <496A28D6.90104@googlemail.com>
Message-ID: <496BA788.1030206@email.it>

Benjamin Hawkes-Lewis ha scritto:
>
>> After all, support for unknown attributes/elements has never been a
>> standard "de jure", but more of a quirk
>
> Depends what you mean by "support" I guess.
>

I just mean that, as far as I know, there is no official standard 
requiring UAs to support (parse and expose through the DOM) attributes 
and elements which are not part of the HTML language but are found in 
text/html documents. Usually, browsers support them for robustness sake 
and/or backward compatibility with existing pages, but they might do it 
with significant differences (actually it happens for unknown elements 
but not for unknown attributes, but one shouldn't assume such common 
behavior might not change in the future, or that will be adopted by 
newer vendors (even if that might be a quite safe assumption), thus any 
hack to the language /for custom purposes and script elaboration/ should 
be done by the mean of existing attributes/elements instead of creating 
new ones (I mean, "data-rdfa-about" might be a bit safer than just 
"about" to use a conservative approach based on the assumption "I know 
what happens today, not what will happen tomorrow") -- before data-* it 
was possible through the class attribute, now also data-* can be used 
for custom hacks)

>> I really don't see the problem if a *custom* convention became widely
>> accepted and reused by other people
>
> Then you I think you don't agree with the fundamental design principle 
> of the "data-*" attribute. The theory is that extensions to HTML 
> benefit from going through a community process like WHATWG or W3C, and 
> blessing extension points encourages people to circumvent that 
> process, with the result that browsers have to support poorly designed 
> features in order to have an interoperable web.
>

Yet it is *possible* to use data-* attributes to define a proper 
*private* convention by choosing names carefully in order to avoid 
clashes with other private conventions (for instance, a widget might 
need metadata to be put within the host page, and a careful choice of 
data-* names might avoid clashes with other metadata needed by other 
widgets or by the page itself). More people might find a certain 
convention useful and enough reusable for their purposes (because of 
non-clashing names), and the result would be a clearer "caw path" that 
community "cawboys" might follow to catch the free problem running away 
from standards.

The *only* difference with "data-rdfa-*" here would be that a higher 
number of authors/developers should agree with such a convention from 
the beginning, but only if they were interested in exchanging the same 
metadata with each others for their respective *custom* uses (through a 
custom script or plugin, either developed independently or shared). From 
this point of view, the only difference between "data-rdfa-about" and 
"about" - as used for the purposes of SearchMonkey - is that the former 
is immediately conforming to HTML5 spec and, thus, surely exposed 
through the DOM by every possible HTML5 compliant UA, as it happens for 
classes used by Microformats. I've never thought to any requirements for 
UAs not coming from a clearly traced "caw path", the same way there is 
no requirement for UAs not involved in SearchMonkey to support any kind 
of metadata - for the purposes of SearchMonkey itself.

Unless one thinks that everyone facing a problem not solved (at all or 
enough for his purposes) by an official standard should either create a 
private hack disregarding any possible hacks for similar problems he 
might have happened to find on the web, or start a new community process 
eventually without knowing if other people are facing the same problem, 
or a similar one, I really can't understand why a *custom* and 
*born-private* (eventually within a group of authors/developers) and 
then become a widely accepted convention should be a problem, as far as 
it is based on existing, standard features and doesn't require any 
additional support and results in a possible cawpath to be then 
standardized as needed. And I really don't understand why class="xyz" is 
a good hack whereas "data-some-thing" is not, assuming both are designed 
for and used by "caws opening a path" ( :-P )

>> I really can't get, right now, why it should be different, for instance,
>> from the case of a freely reusable widget using a custom data model
>> based on private data-* attributes inserted by people in thousands of
>> websites (the widget with relitive metadata, I mean), then liked by
>> other people and reused in different contexts (the same data model based
>> on data-*, now)
>
> Reuse of "data-*" by DHTML widgets would not impose any additional 
> requirements on user agents, so it would be fine from the perspective 
> elaborated above. It wouldn't change the language by the back door.

Really? Is it so much different from the case of the pattern attribute 
(which addresses, at the UA and language level, a problem earlier solved 
by scripts -- e.g. getting elements by their ids)? I don't think it's 
very different. From this perspective, if data-* attributes existed 
before the pattern attribute, someone might have used them to declare a 
regex then used by a script implementing a generic checking, and such 
might have been a good reason to add the pattern attribute to form 
inputs, requiring UAs to contrast the input value to its relative 
regular expression (a solution wich also works for UAs not supporting 
scripts, for instance).

I guess closing a language to every kind of "back-door changes" may be 
in contrast with the principle of paving a cawpath. I also guess that, 
if microformats experience (or the "realworld semantics" they claim to 
be based on) had suggested the need to add a new element/attribute to 
the language, a new element/attribute would have been added.

WBR, Alex

 
 
 --
 Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f
 
 Sponsor:
 Partecipa al concorso Danone Activia e vinci MacBook Air e Nokia N96. Prova
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8550&d=12-1


From bhawkeslewis at googlemail.com  Mon Jan 12 14:14:14 2009
From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis)
Date: Mon, 12 Jan 2009 22:14:14 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <496BA788.1030206@email.it>
References: <061D9684-D7A9-48F0-A042-F71AEEE865C9@tobyinkster.co.uk>	<41E096C93F384F9BA6B0A09A87EF8E97@POCZTOWIEC>	<D2E95E63-AF9B-42F1-A1D8-8FE82BDB8CEE@tobyinkster.co.uk>	<48B5D840.5000704@digitalbazaar.com>	<Pine.LNX.4.62.0812310239160.24109@hixie.dreamhostps.com>	<op.um19y5ajwxe0ny@widsithpro.lan>	<495F97A9.1080602@email.it>
	<op.um7lz7ufwxe0ny@widsithpro.lan>	<4966AE40.3040600@email.it>	<2E944B0D-0AB0-4099-8CA4-5F55ABA52E67@geekhood.net>
	<49695EA4.1060302@email.it> <4969BED3.9010401@googlemail.com>
	<496A23D8.9090901@email.it> <496A28D6.90104@googlemail.com>
	<496BA788.1030206@email.it>
Message-ID: <496BC0B6.2060906@googlemail.com>

On 12/1/09 20:26, Calogero Alex Baldacchino wrote:
> I just mean that, as far as I know, there is no official standard
> requiring UAs to support (parse and expose through the DOM) attributes
> and elements which are not part of the HTML language but are found in
> text/html documents.

Perhaps, but then prior to HTML5, much of what practical user agents 
must do with HTML has not been required by any official standard. ;)

RFC 2854 does say that "Due to the long and distributed development of 
HTML, current practice on the Internet includes a wide variety of HTML 
variants. Implementors of text/html interpreters must be prepared to be 
'bug-compatible' with popular browsers in order to work with many HTML 
documents available the Internet."

http://tools.ietf.org/html/rfc2854

HTML 4.01 does recommend that "[i]f a user agent encounters an element 
it does not recognize, it should try to render the element's content" 
and "[i]f a user agent encounters an attribute it does not recognize, it 
should ignore the entire attribute specification (i.e., the attribute 
and its value)".

http://www.w3.org/TR/html401/appendix/notes.html#h-B.3.2

Clearly these suggestions are incompatible with respect to attributes; 
AFAIK all popular UAs insert unrecognized attributes into the DOM and 
plenty of web content depends on that behaviour.

>> Reuse of "data-*" by DHTML widgets would not impose any additional
>> requirements on user agents, so it would be fine from the perspective
>> elaborated above. It wouldn't change the language by the back door.
>
> Really? Is it so much different from the case of the pattern attribute
> (which addresses, at the UA and language level, a problem earlier solved
> by scripts -- e.g. getting elements by their ids)? I don't think it's
> very different. From this perspective, if data-* attributes existed
> before the pattern attribute, someone might have used them to declare a
> regex then used by a script implementing a generic checking, and such
> might have been a good reason to add the pattern attribute to form
> inputs, requiring UAs to contrast the input value to its relative
> regular expression (a solution wich also works for UAs not supporting
> scripts, for instance).

Just like proprietary elements/attributes introduced with user agent 
behaviours (marquee, autocomplete, canvas), scripted uses of "data-*" 
might suggest new features to be added to HTML, which would then become 
requirements for UAs.

But unlike proprietary elements/attributes introduced with user agent 
behaviors, scripted uses of "data-*" do not impose new processing 
requirements on UAs.

Therefore, unlike proprietary elements/attributes introduced with user 
agent behaviors, scripted uses of "data-*" impose _no_ design 
constraints on new features.

Establishing user agent behaviours with "data-*" attributes, on the 
other hand, imposes almost as many design constraints as establishing 
them with proprietary elements and attributes. (There's just less 
pollution of the primary HTML "namespace".)

If no RDFa was in deployment, you could argue it would be less wrong 
(from this perspective) to abuse "data-*" than introduce new attributes.

But to the extent that these attributes are already in use in text/html 
and standardized within the "http://www.w3.org/1999/xhtml" namespace, 
processing requirements are effectively already being imposed on user 
agents (such as not introducing conflicting treatment of the "about" 
attribute). All that adding user agent behaviours with "data-rdfa*" 
attributes would do at this point is add _more_ requirements, without 
rescuing the polluted attributes.

 > I also guess that,
> if microformats experience (or the "realworld semantics" they claim to
> be based on) had suggested the need to add a new element/attribute to
> the language, a new element/attribute would have been added.

I'm not really sure what you mean.

(It's watching the microformats community struggle with the problem of 
encoding machine data equivalents, for things like dates and telephone 
number types and measurements, that persuaded me HTML5 should include a 
generic machine data attribute, because it seems likely to me that the 
problem will be recurrent.)

--
Benjamin Hawkes-Lewis


From mail at tobyinkster.co.uk  Mon Jan 12 15:15:51 2009
From: mail at tobyinkster.co.uk (Toby A Inkster)
Date: Mon, 12 Jan 2009 23:15:51 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
Message-ID: <B3FA8D6C-A5E7-465F-9113-52DD48DF3E00@tobyinkster.co.uk>

Henri Sivonen wrote:

> eRDF is very different in not relying on attributes whose qname
> contains the substring "xmlns".


eRDF is very different in that it is incredibly annoying to use in  
real world scenarios (i.e. not hypothetical "Hello World" examples).

Calogero Alex Baldacchino wrote:

> I guess closing a language to every kind of "back-door changes" may be
> in contrast with the principle of paving a cawpath. I also guess that,
> if microformats experience (or the "realworld semantics" they claim to
> be based on) had suggested the need to add a new element/attribute to
> the language, a new element/attribute would have been added.

But Microformats experience *does* suggest that new attributes are  
needed for semantics. Look at the debate around accessibility within  
Microformats which has been going on for ages. Because of the  
Microformats process of working *within* existing HTML standards it  
has not been solved, and I can't see a solution reaching consensus in  
the foreseeable future. HTML5's <time> goes part of the way to  
solving this, but it doesn't address the whole problem like RDFa's  
"content" attribute does.

Another reason the Microformat experience suggests new attributes are  
needed for semantics is the overloading of an attribute (class)  
previously mainly used for private convention so that it is now used  
for public consumption. Yes, in real life, there are pages that use  
class="vcard" for things other than encoding hCard. (They mostly use  
it for linking to VCF files.) Incredibly, I've even come across pages  
that use class="vcard" for non-hCard uses, *and* hCard - yes, on the  
same page! As the Microformat/POSHformat space becomes more crowded,  
accidental collisions in class names become ever more likely.

The Microformats community hasn't added any new attributes for  
Microformats, because that was one of the guiding principles when the  
community was established: however, that does not mean it hasn't  
shown that new attributes are needed for encoding rich semantics in  
HTML. On the contrary, I think it's proved that they are.

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



From annevk at opera.com  Mon Jan 12 15:57:15 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 13 Jan 2009 00:57:15 +0100
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com>
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com>
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost>
Message-ID: <op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>

On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie  
<stewart.brodie at antplc.com> wrote:
> Ian Hickson <ian at hixie.ch> wrote (on 25 July 2008):
>> I've made [getElementsByClassName] consistent with how classes work in  
>> CSS
>> (case-insensitive for quirks and case-sensitive otherwise).
>
> I was looking for some tests for this API and found some from Opera  
> (found
> at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the
> dates on them predate the latest spec changes (which causes some to fail
> now), I was wondering if up to date versions are now kept somewhere else
> instead?

The tests already take this change into account. It was agreed upon way  
earlier prolly over IRC or so, but the specification hadn't catched up  
with reality yet. I'm not sure what other tests you might believe to be  
out of date (and why) and would be interested in knowing being the author  
and all :-)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From andi at takkaria.org  Mon Jan 12 18:09:35 2009
From: andi at takkaria.org (Andi Sidwell)
Date: Tue, 13 Jan 2009 02:09:35 +0000
Subject: [whatwg] Trying to work out the problems solved by RDFa
In-Reply-To: <B3FA8D6C-A5E7-465F-9113-52DD48DF3E00@tobyinkster.co.uk>
References: <B3FA8D6C-A5E7-465F-9113-52DD48DF3E00@tobyinkster.co.uk>
Message-ID: <496BF7DF.1050404@takkaria.org>

On 2009-01-12 23:15, Toby A Inkster wrote:
> Henri Sivonen wrote:
>
>> eRDF is very different in not relying on attributes whose qname
>> contains the substring "xmlns".
>
>
> eRDF is very different in that it is incredibly annoying to use in real
> world scenarios (i.e. not hypothetical "Hello World" examples).
>
> Calogero Alex Baldacchino wrote:
>
>> I guess closing a language to every kind of "back-door changes" may be
>> in contrast with the principle of paving a cawpath. I also guess that,
>> if microformats experience (or the "realworld semantics" they claim to
>> be based on) had suggested the need to add a new element/attribute to
>> the language, a new element/attribute would have been added.
>
> But Microformats experience *does* suggest that new attributes are
> needed for semantics. Look at the debate around accessibility within
> Microformats which has been going on for ages. Because of the
> Microformats process of working *within* existing HTML standards it has
> not been solved, and I can't see a solution reaching consensus in the
> foreseeable future. HTML5's <time> goes part of the way to solving this,
> but it doesn't address the whole problem like RDFa's "content" attribute
> does.

Right, so some microformats brought to attention a need which HTML5 
could easily solve by adding <time>.  Why does this mean that RDFa 
should be added?

> Another reason the Microformat experience suggests new attributes are
> needed for semantics is the overloading of an attribute (class)
> previously mainly used for private convention so that it is now used for
> public consumption.

But HTML4 itself says that class can be used "for general purpose 
processing by user agents", so this seems to be a weird argument.  If we 
introduced RDFa and it got used, would you argue you need something more 
than RDFa, because it is being used for what it is specced for?

> Yes, in real life, there are pages that use
> class="vcard" for things other than encoding hCard. (They mostly use it
> for linking to VCF files.) Incredibly, I've even come across pages that
> use class="vcard" for non-hCard uses, *and* hCard - yes, on the same
> page! As the Microformat/POSHformat space becomes more crowded,
> accidental collisions in class names become ever more likely.

Right, but is it much of an issue?  If you have a hCard extractor, the 
user can see easily that it's not useful data.  And if doesn't follow 
any of the other rules for an hCard, then the UA can safely ignore it 
(e.g. it has no fields).  In practice, this kind of collision seems 
fairly non-problematic.

> The Microformats community hasn't added any new attributes for
> Microformats, because that was one of the guiding principles when the
> community was established: however, that does not mean it hasn't shown
> that new attributes are needed for encoding rich semantics in HTML. On
> the contrary, I think it's proved that they are.

Given that the only example of the microformats process needing an 
addition to the HTML language has been <time>, I'm not sure that's a 
conclusive proof.

Andi


From ian at hixie.ch  Tue Jan 13 01:40:05 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Jan 2009 09:40:05 +0000 (UTC)
Subject: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
In-Reply-To: <E2CC0E97-39B5-4126-86EC-AD801634DA7D@apple.com>
References: <4B99A607-E778-43BF-B71D-8DFAC2BE022A@apple.com>
	<070C62C5-2AB7-4F22-A230-A7C43BCB8D59@apple.com>
	<9CAF2F9F-6811-4247-8C32-60AAC376E8C8@apple.com>
	<EE35A8FB-C86A-4AC8-AF85-61CA9FBF31F6@apple.com>
	<E2CC0E97-39B5-4126-86EC-AD801634DA7D@apple.com>
Message-ID: <Pine.LNX.4.62.0901130930370.7181@hixie.dreamhostps.com>


On Sun, 18 May 2008, Maciej Stachowiak wrote:
> On May 18, 2008, at 3:18 PM, Brady Eidson wrote:
> >
> > While I'm on the topic, I'm also curious about that [XXX] placeholder. 
> > There's a bug in WebKit's bugzilla pointing out that the IE8 beta and 
> > Firefox 2 both support `delete storage.keyName` syntax as an alias for 
> > `storage.removeItem(keyName)`
> >
> > I'm taking a guess here and assuming supporting the `delete` syntax is 
> > the implied concept behind [XXX]
> 
> WebKit's JavaScript engine doesn't currently have the ability to run 
> custom code when a property is deleted. It would be a significant 
> challenge to add this capability and possibly a performance regression; 
> and no other DOM-related spec requires this, even when there is 
> NameGetter or IndexGetter behavior. For example NodeLists and 
> HTMLCollections do not let you delete by name to remove the item (I'm 
> not sure what that would even mean). So I'd prefer not to have to 
> introducethis concept just for this one case.

On Sun, 18 May 2008, Brady Eidson wrote:
> 
> WebKit has the ability to add custom property deletion on a per-class 
> basis - therefore not slowing down the common case at all.  That's how I 
> fixed the bug to make us compatible with IE8 and Firefox for now as this 
> debate gets underway...

On Mon, 19 May 2008, Geoffrey Garen wrote:
> 
> It is *very* weird, and therefore not a "useful shorthand."
> 
> In JavaScript, "delete" means "remove this property / interface from 
> this JavaScript object." I can't think of any context in which it means 
> anything else.
> 
> For example, "delete node.parentNode" attempts to remove the 
> "parentNode" property from "node". It does not remove "parentNode" from 
> the document or anything like that.
> 
> "delete window" attempts to remove the "window" property from the global 
> object. It does not close the window or anything like that.
> 
> In other words, you can be certain that "delete" is a simple operation 
> with a consistent side-effect.
> 
> As a JavaScript programmer, I would find it very difficult to reason 
> about objects that might or might not change the behavior of the 
> "delete" operator. One reason i would find it very difficult is that 
> operator overloading does not exist in JavaScript at all, so to 
> understand this one API, I would need to understand a vast corpus of 
> programming language goobery that is not at all covered in any 
> JavaScript manual. Another reason I would find it very difficult is that 
> the overloaded meaning of "delete" here ("remove persistent storage from 
> disk") is far afield from the original meaning ("remove interface from 
> temporary object in memory"). To give you an analogy, even in C++, where 
> you're allowed to overload operator delete, if you overloaded operator 
> delete to mean "do not free this object's memory, but do delete the file 
> it references from the file system", well, let's just say that your 
> patch would not pass code review with any of your four reviewers :).
> 
> I am not sure if any JS decoration or collection libraries depend on the 
> canonical behavior of operator delete, but if they do, I would hate for 
> them all to have to ship with the asterisk, "BEWARE: do NOT use this 
> decoration / collection library with that one weird DOM object that 
> interprets 'delete' to mean 'remove important data from the user's 
> disk'". Oy!

On Mon, 19 May 2008, Brady Eidson wrote:
> 
> I'm unsure if you have the proper background with the Storage interface 
> that is in question here.  I'm guessing that the reason that Firefox 2 
> and IE8 support the "modified" behavior of delete for Storage items is 
> because the "way of thinking about Storage items" we're trying to get 
> across meets most of the expectations of manipulating properties that 
> you lay out below.
> 
> On May 19, 2008, at 3:18 PM, Geoffrey Garen wrote:
> > 
> > In JavaScript, "delete" means "remove this property / interface from 
> > this JavaScript object." I can't think of any context in which it 
> > means anything else.
> 
> The spec makes it clear that storage items and properties on the Storage 
> object are interchangeable.
>
> `storage.foo = "bar"` happens to be equivalent to 
> `storage.setItem("foo", "bar")`, but is also no different from 
> `someRandomObject.foo = "bar"` as far as keeping a collection of 
> properties on an object.
> 
> This also applies for enumeration, etc.
> 
> Equivalently and more relevant to the discussion, `delete storage.foo` 
> happens to be equivalent to `storage.removeItem("foo")`, but is also 
> *little* different from `delete someRandomObject.foo`
> 
> > For example, "delete node.parentNode" attempts to remove the 
> > "parentNode" property from "node". It does not remove "parentNode" 
> > from the document or anything like that.
> >
> > "delete window" attempts to remove the "window" property from the 
> > global object. It does not close the window or anything like that.
> 
> In the SessionStorage case, this applies with zero caveats.  In the 
> LocalStorage case, it applies with the caveat that "all of the 
> properties you set on this object will still be on this object's analog 
> the next time you restart the browser and come back to this page"
> 
> And that's the really weird thing, I think - window.localStorage can be 
> thought of exactly like every other javascript object, except it is not 
> temporary.  It gets created once and maintains it's state over browser 
> launches.  We're already breaking the javascript-assumption-mold when 
> you get into that mindset.
> 
> Neither IE8 or FFX have implemented LocalStorage in a release yet, so 
> perhaps they would not support the syntax for LocalStorage, and only 
> support it for SessionStorage.  Of course that would be even weirder, 
> having 2 concrete implementations of the same interface have "API 
> incompatibilities"
> 
> > In other words, you can be certain that "delete" is a simple operation 
> > with a consistent side-effect.
> >
> > As a JavaScript programmer, I would find it very difficult to reason 
> > about objects that might or might not change the behavior of the 
> > "delete" operator.
> 
> Is the behavior of the delete operator "remove the property from the 
> object" or is it actually "remove the property from the object with zero 
> other detectable side effects"?
> 
> > One reason i would find it very difficult is that operator overloading 
> > does not exist in JavaScript at all, so to understand this one API, I 
> > would need to understand a vast corpus of programming language goobery 
> > that is not at all covered in any JavaScript manual.
> 
> I think this is a pretty shameful exaggeration ;)
> 
> > Another reason I would find it very difficult is that the overloaded 
> > meaning of "delete" here ("remove persistent storage from disk") is 
> > far afield from the original meaning ("remove interface from temporary 
> > object in memory").
> 
> The overloaded meaning of "delete" here is "remove interface from 
> temporary object in memory, as well as the persistent record of its 
> existence."  Still different from the original meaning, but not "far 
> afield" different.
> 
> > To give you an analogy, even in C++, where you're allowed to overload 
> > operator delete, if you overloaded operator delete to mean "do not 
> > free this object's memory, but do delete the file it references from 
> > the file system", well, let's just say that your patch would not pass 
> > code review with any of your four reviewers :).
> 
> But if you overloaded the delete operator to free the object's memory 
> *and* delete its referenced files from the file system, you'd be using 
> the operator overloading in its intended capacity.
> 
> > I am not sure if any JS decoration or collection libraries depend on 
> > the canonical behavior of operator delete, but if they do, I would 
> > hate for them all to have to ship with the asterisk, "BEWARE: do NOT 
> > use this decoration / collection library with that one weird DOM 
> > object that interprets 'delete' to mean 'remove important data from 
> > the user's disk'". Oy!
> 
> At the same time, why not be concerned that such a collection library 
> happens to expose the exact same API interface that the Storage object 
> exposes, and now that library should carry the same warning saying 
> "BEWARE: do NOT use this collection library with that one weird DOM 
> object that interprets 'clear()' to mean 'remove important data from the 
> user's disk'?
> 
> The fact that we're giving scripts the ability to directly manipulate 
> data on the users disk is already a jump-off-a-bridge as far as I'm 
> concerned. Shouldn't a script writer using LocalStorage use due 
> diligence to make sure his data is actually safe as expected?

On Mon, 19 May 2008, Maciej Stachowiak wrote:
>
> I think the analogy between delete in C++ and delete in JavaScript is 
> strained. First of all, the two delete operators do totally different 
> things. Second, C++ supports general operator overloading for nearly 
> every operator. The right analogy would be removing objects from 
> collections, and C++ does not have a special operator for that.
> 
> (But as a side note I think it would be poor style for C++ code to 
> overload operator delete to remove files from the filesystem. The right 
> place to do additional resource management would be the destructor.)
> 
> I do agree that the spec should define a single interoperable behavior 
> and we should all converge.

On Tue, 20 May 2008, Kristof Zelechovski wrote:
>
> Suppose you successfully delete a property of an object that gets 
> ultimately persisted that object on the server using XMLHttpRequest with 
> JSON.  Your action of deleting the property is absolutely legal and it 
> undoubtedly has side effects.  How is it different from the local 
> storage case, except that it is persisted implicitly by the session 
> manager?
>
> In other words, deleting a property from local storage does not change 
> anything in persistent memory by itself; it is the session manager that 
> executes the change afterwards.  It is possible because the local 
> storage belongs to the global state.  The operator delete is not 
> overloaded.

On Mon, 19 May 2008, Maciej Stachowiak wrote:
> 
> I looked into this and in all other cases we use an override of delete 
> for the following effects:
> 
> - Special case for Arrays since they store some of their properties 
> differently.
> - Prevent deletion (though it would be better in most of these cases to 
> just rely on DontDelete attributes)/
> - Cross-site scripting security checks on delete.
> 
> I think the Storage case would be more complicated than this, because it 
> dispatches an event and so can run arbitrary JavaScript code. I think 
> our JS interpreter is likely not prepared for "delete" executing 
> arbitrary JS code, and so may crash when this happens. We can fix it, 
> but I think delete having special behavior is not that great from the 
> point of design.
> 
> Comparing conciseness and familiarity:
> 
> storage.keyName
> storage.getItem('keyName')
> 
> storage.keyName = 'value';
> storage.setItem('keyName', 'value');
> 
> delete storage.keyName;
> storage.removeItem('keyName');
> 
> The getter seems like the biggest relative increase in conciseness, and 
> the getter and setter will both be much more familiar with operator 
> syntax. But delete is fairly rarely used (and unlike getters and setters 
> does not allow overriding at the JS level in many implementations) so 
> the syntax is not much more familiar. The improvement in conciseness is 
> also less.
> 
> We should also keep in mind that overloading operators is kind of a big 
> deal and should not be done lightly. If the HTML5 spec required custom 
> behavior for * or && for certain objects rather than following the JS 
> rules I think we would all be pretty concerned.
> 
> So I'd rather avoid messing with the (relative) purity of the delete 
> operator.

On Tue, 20 May 2008, Robert O'Callahan wrote:
>
> If "storage.keyName = 'value';" can create a new storage item 
> (persistently), won't authors expect "delete storage.keyName;" to remove 
> it (persistently), as a matter of consistency?
> 
> If overloading "delete" is too quirky or too hard to implement, then it 
> seems none of the other shorthands should be allowed either.

On Mon, 19 May 2008, Maciej Stachowiak wrote:
> 
> Many objects in the DOM implement custom name getters (for instance 
> NodeList) and a few even implement custom name setters 
> (CSSStyleDeclaration, at least the way it is done in WebKit) but no one 
> has clamored for a custom deleter or expected delete to work "as a 
> matter of consistency" or been confused that "style.opacity = 0" is 
> allowed but "delete style.opacity" is not. So I would say the available 
> evidence argues against your conclusions.

On Mon, 19 May 2008, Brady Eidson wrote:
> 
> I am a lot more swayed by this argument against adoption.
> 
> At this point, my concerns are not of a technical nature, but rather of 
> a "real life web" nature - either you force FFX and IE8 to remove it, 
> you have others adopt it, or the spec introduces a de facto 
> incompatibility on the web.
> 
> I have no solution, only this particular awareness of the problem.

Since we have implementations, and implementors don't seem willing to 
remove it, I haven't removed the 'delete' functionality for Storage.

I have, however, removed the similar functionality in UndoManager, lest 
someone implement it.



On Tue, 20 May 2008, Maciej Stachowiak wrote:
> Ian wrote:
> >
> > Originally, I wanted Storage objects to be indistinguishable from 
> > Object objects in JS, and native hash or collection objects in other 
> > bindings. Conceptually, that's what these objects are -- native 
> > name/value pair collections that happen to be mapped to non-volatile 
> > storage (or somewhat- volatile storage, in the case of 
> > sessionStorage).
> 
> Normal objects don't fire DOM events when you change their properties (I 
> imagine the same may be true of native hash objects in at least some 
> languages), so the indistinguishability only goes so far.

Well, .watch() supported by some UAs somewhat goes against this. But ok.


> > I'd also like the "delete" operator to work on DOMStringMap (for the 
> > dataset object -- calling 'delete' on that has the side-effect of 
> > removing the underlying attribute) and UndoManager (where the 
> > side-effect is to remove the entry and renumber the following entries, 
> > so maybe that's not such a good idea after all), for what it's worth. 
> > If we want to decide that we're not supporting this, we should decide 
> > that before implementations of those come about.
> 
> Those both sound suboptimal to me. UndoManager because it remove more 
> than the one item, and DOMStringMap because (a) you can't delete from 
> NamedNodeMap to remove an attribute so it would be inconsistent and (b) 
> removing an attribute causes a mutation event to fire and thus runs 
> arbitrary code (creating the same problem of 'delete' running arbitrary 
> code as Storage).
> 
> > For DOMStringMap, my intention was to not provide methods at all, and 
> > only provide the JS-native mechanisms.
> 
> A bold choice, but I would not recommend it as the sole available 
> mechanism.

See above for UndoManager, but for DOMStringMap I don't want to add any 
other mechanisms, because they introduce name clashes. Right now the IDL 
for DOMStringMap is:

   [NameCreator, NameDeleter, NameGetter, NameSetter]
   interface DOMStringMap {};

It basically emulates a JS Object. It's intended only for JS. I don't see 
why this is a bad idea.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan 13 01:41:46 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Jan 2009 09:41:46 +0000 (UTC)
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
Message-ID: <Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>

On Mon, 28 Apr 2008, Brady Eidson wrote:
> 
> Anne was asserting that since the interface for setItem() specifies a 
> DOMString as the input, anything you pass it will be stringified.  
> Therefore passing it the null value would be stringified to "null".  
> This is what you currently see in all the major browsers with 
> window.alert(null), for example, which is also specified as a DOMString 
> input parameter.
> 
> Therefore a call to setItem("foo", null); becomes, in effect, 
> setItem("foo", "null");
> 
> Is this correct?
> 
> If so, the spec is fine as-is, and removeItem() is the only way to 
> remove an individual item.

That is correct, at least currently. I am tempted to change this to 
[Null=Empty], though (i.e. make 'null' act like the empty string). 
However, I'm somewhat stuck on this as it depends on what happens with 
[Null] in WebIDL.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From stewart.brodie at antplc.com  Tue Jan 13 02:08:56 2009
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Tue, 13 Jan 2009 10:08:56 +0000
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com> 
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com> 
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost> 
	<op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>

Anne van Kesteren <annevk at opera.com> wrote:

> On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie
> <stewart.brodie at antplc.com> wrote:
> > Ian Hickson <ian at hixie.ch> wrote (on 25 July 2008):
> >> I've made [getElementsByClassName] consistent with how classes work in
> >> CSS
> >> (case-insensitive for quirks and case-sensitive otherwise).
> >
> > I was looking for some tests for this API and found some from Opera
> > (found
> > at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the
> > dates on them predate the latest spec changes (which causes some to fail
> > now), I was wondering if up to date versions are now kept somewhere else
> > instead?
> 
> The tests already take this change into account. It was agreed upon way
> earlier prolly over IRC or so, but the specification hadn't catched up
> with reality yet. I'm not sure what other tests you might believe to be
> out of date (and why) and would be interested in knowing being the author
> and all :-)

Specifically: test 14 - tests for case-sensitivity in a document that is in
quirks mode.

Are you saying that this change has now been reversed and the comparisons
are always case-sensitive, thus reintroducing the discrepancy between CSS's
handling of classes and this new method?


-- 
Stewart Brodie
Software Engineer
ANT Software Limited


From ian at hixie.ch  Tue Jan 13 02:15:59 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Jan 2009 10:15:59 +0000 (UTC)
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com> 
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com> 
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost> 
	<op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>
	<47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>
Message-ID: <Pine.LNX.4.62.0901131014480.29785@hixie.dreamhostps.com>

On Tue, 13 Jan 2009, Stewart Brodie wrote:
> Anne van Kesteren <annevk at opera.com> wrote:
> 
> > On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie
> > <stewart.brodie at antplc.com> wrote:
> > > Ian Hickson <ian at hixie.ch> wrote (on 25 July 2008):
> > >> I've made [getElementsByClassName] consistent with how classes work in
> > >> CSS
> > >> (case-insensitive for quirks and case-sensitive otherwise).
> > >
> > > I was looking for some tests for this API and found some from Opera
> > > (found
> > > at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the
> > > dates on them predate the latest spec changes (which causes some to fail
> > > now), I was wondering if up to date versions are now kept somewhere else
> > > instead?
> > 
> > The tests already take this change into account. It was agreed upon way
> > earlier prolly over IRC or so, but the specification hadn't catched up
> > with reality yet. I'm not sure what other tests you might believe to be
> > out of date (and why) and would be interested in knowing being the author
> > and all :-)
> 
> Specifically: test 14 - tests for case-sensitivity in a document that is in
> quirks mode.
> 
> Are you saying that this change has now been reversed and the 
> comparisons are always case-sensitive, thus reintroducing the 
> discrepancy between CSS's handling of classes and this new method?

I'm not familiar with the tests, but as far as I know the spec is up to 
date here. I'm not aware of any outstanding feedback on this area. Anne?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From annevk at opera.com  Tue Jan 13 02:17:08 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 13 Jan 2009 11:17:08 +0100
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com>
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com>
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost>
	<op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>
	<47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>
Message-ID: <op.unoxiuf464w2qv@annevk-t60.oslo.opera.com>

On Tue, 13 Jan 2009 11:08:56 +0100, Stewart Brodie  
<stewart.brodie at antplc.com> wrote:
> Specifically: test 14 - tests for case-sensitivity in a document that is  
> in quirks mode.
>
> Are you saying that this change has now been reversed and the comparisons
> are always case-sensitive, thus reintroducing the discrepancy between  
> CSS's handling of classes and this new method?

Since my initial e-mail did not seem to have done it, could you please  
take a look at the source code of the respective test and tell me if you  
see a problem there?

   http://tc.labs.opera.com/apis/getElementsByClassName/014.htm

To be perfectly clear, there is no discrepancy between CSS handling and  
the getElementsByClassName method and the test is testing that there is  
not.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From ian at hixie.ch  Tue Jan 13 02:23:04 2009
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Jan 2009 10:23:04 +0000 (UTC)
Subject: [whatwg] DOMStringMap named properties
In-Reply-To: <20081217230508.GA19250@arc.mcc.id.au>
References: <20081217230508.GA19250@arc.mcc.id.au>
Message-ID: <Pine.LNX.4.62.0901131016390.7181@hixie.dreamhostps.com>

On Thu, 18 Dec 2008, Cameron McCormack wrote:
> 
> > [19:38] <Hixie> heycam: i'd much rather have the idl look like the js
> >   object and have [IndexSetter] etc take arguments to provide names
> >   for the other languages
> 
> But would you add those names? :)

Probably not. :-)


> If you definitely don?t want to use [NoIndexingOperations]

I'd rather not. Say this was implemented in Perl, for instance. I'd want 
to see this implemented as a tied hash, not as a hashref with methods. I 
don't know that the current IDL would be enough, and I wouldn't know how 
to write hte IDL today for that case either. Better, IMHO, to not specify 
that yet, and if it comes up, we can write IDL for that language.


> then the section should look like the following:
> 
>   The DOMStringMap interface represents a set of name-value pairs. When
>   a DOMStringMap object is instantiated, it is associated with three
>   algorithms: one for getting the list of name-value pairs, one for
>   setting names to certain values, and one for deleting names.
> 
>     [NameGetter, NameSetter, NameCreator, NameDeleter]
>     interface DOMStringMap {
>     };
> 
>   The names of the supported named properties on a DOMStringMap object
>   are the names of each pair returned by the algorithm for getting the
>   list of name-value pairs.
> 
>   When a DOMStringMap object is indexed to retrieve a named property
>   /name/, the following algorithm must be run:
> 
>     1. Let /pairs/ be the list returned from the algorithm for getting
>        the list of name-value pairs.
>     2. Let /pair/ be the entry in /pairs/ whose name component is equal
>        to /name/.
>     3. Return the value component of /pair/.
> 
>   When a DOMStringMap object is indexed to create or modify a named
>   property /name/ with value /value/, the algorithm for setting names to
>   certain values must be run, passing /name/ as the name and the
>   result of converting /value/ to a DOMString as the value.
> 
>   When a DOMStringMap object is indexed to delete a named property named
>   /name/, the algorithm for deleting names must be run, passing /name/
>   as the name.

I haven't quite used your text, but I used something much more like it 
than there was before. Please let me know if any of the discrepancies are 
problems I missed.


> If you go without [NoIndexingOperations], then I suggest specifying 
> somehow that HTMLElement::dataset only exist in language bindings that 
> support object indexing, or only in ECMAScript.

Added a note.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From annevk at opera.com  Tue Jan 13 02:23:13 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 13 Jan 2009 11:23:13 +0100
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <op.unoxiuf464w2qv@annevk-t60.oslo.opera.com>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com>
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com>
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost>
	<op.unn4tpps64w2qv@annevk-t60.oslo.opera.com>
	<47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost>
	<op.unoxiuf464w2qv@annevk-t60.oslo.opera.com>
Message-ID: <op.unoxsz1h64w2qv@annevk-t60.oslo.opera.com>

On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren <annevk at opera.com>  
wrote:
> Since my initial e-mail did not seem to have done it, could you please  
> take a look at the source code of the respective test and tell me if you  
> see a problem there?
>
>    http://tc.labs.opera.com/apis/getElementsByClassName/014.htm
>
> To be perfectly clear, there is no discrepancy between CSS handling and  
> the getElementsByClassName method and the test is testing that there is  
> not.

Wow, epic fail. I missed it should match two elements. The test is indeed  
out of date.

* updates the test now.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From jonas at sicking.cc  Tue Jan 13 04:44:22 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 13 Jan 2009 04:44:22 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
Message-ID: <63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>

On Tue, Jan 13, 2009 at 1:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 28 Apr 2008, Brady Eidson wrote:
>>
>> Anne was asserting that since the interface for setItem() specifies a
>> DOMString as the input, anything you pass it will be stringified.
>> Therefore passing it the null value would be stringified to "null".
>> This is what you currently see in all the major browsers with
>> window.alert(null), for example, which is also specified as a DOMString
>> input parameter.
>>
>> Therefore a call to setItem("foo", null); becomes, in effect,
>> setItem("foo", "null");
>>
>> Is this correct?
>>
>> If so, the spec is fine as-is, and removeItem() is the only way to
>> remove an individual item.
>
> That is correct, at least currently. I am tempted to change this to
> [Null=Empty], though (i.e. make 'null' act like the empty string).
> However, I'm somewhat stuck on this as it depends on what happens with
> [Null] in WebIDL.

I talked with Cameron a while ago about what the default behavior
should be for null. We couldn't find any functions that required that
null be treated as "null", but there are several examples of functions
that require that null be treated as the empty string.

So from a code purity point of view it would be nicer if we could make
the default behavior be that null is treated as "null" as that would
require fewer exceptions.

The downside is that it would be a bigger change for more UAs than
going the other way around. So there's more risk of compat problems.

/ Jonas


From annevk at opera.com  Tue Jan 13 04:48:29 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 13 Jan 2009 13:48:29 +0100
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
Message-ID: <op.uno4i3eg64w2qv@annevk-t60.oslo.opera.com>

On Tue, 13 Jan 2009 13:44:22 +0100, Jonas Sicking <jonas at sicking.cc> wrote:
> I talked with Cameron a while ago about what the default behavior
> should be for null. We couldn't find any functions that required that
> null be treated as "null", but there are several examples of functions
> that require that null be treated as the empty string.

alert() requires it. Besides that I believe we (Opera) specifically did it  
for methods here and there to be more compatible with Internet Explorer  
and make sites work better.


> So from a code purity point of view it would be nicer if we could make
> the default behavior be that null is treated as "null" as that would
> require fewer exceptions.
>
> The downside is that it would be a bigger change for more UAs than
> going the other way around. So there's more risk of compat problems.

Indeed, I would rather not change Opera's behavior where we stringify just  
like Internet Explorer without some kind of data that shows it will not  
give problems.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From giovanni.gentili at gmail.com  Tue Jan 13 06:18:24 2009
From: giovanni.gentili at gmail.com (Giovanni Gentili)
Date: Tue, 13 Jan 2009 15:18:24 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
Message-ID: <4a30f5360901130618p19f27f25yfcce2b29c2ea02e5@mail.gmail.com>

Martin Atkins wrote:
> One problem this can solve is that an agent can, given a URL that
> represents a person, extract some basic profile information such as the
> person's name along with references to other people that person knows.
> This can further be applied to allow a user who provides his own URL
> (for example, by signing in via OpenID) to bootstrap his account from
> existing published data rather than having to re-enter it.
>
> So, to distill that into a list of requirements:
>
> - Allow software agents to extract profile information for a person as often
> exposed on social networking sites from a page that "represents" that person.
>
> - Allow software agents to determine who a person lists as their friends
> given a page that "represents" that person.
>
> - Allow the above to be encoded without duplicating the data in both
> machine-readable and human-readable forms.
>
> Is this the sort of thing you're looking for, Ian?
>
>Much of the above section could be applied to any other RDF vocabulary
>with a bit of search and replace, but I'll leave that to others since
>FOAF is the only RDF vocabulary with which I have any experience.

Why we must restrict the use case to a single vocabulary
or analyze all the possibile vocabularies?

I think it's be better to "generalize" the problem
and find a unique solution for human/machine.

I tried to expose this here...

http://lists.w3.org/Archives/Public/public-html/2009Jan/0082.html

...where the fundamental problem is described in this way:

- User agents must allow users to see that there are "semantic-links"
(connections to semantically structured informations)
in a HTML document/application. Consequently
user agents must allow users to "follow" the semantic-link,
(access/interact with the linked data, embedded or external)
and this involves primarily the ability to:
a) view the informations
b) select the informations
c) copy the informations in the clipboard
d) drag and drop the informations
e) send that informations
to another web application
(or to OS applications)
selected by the user.

-- 
Giovanni Gentili


From jgraham at opera.com  Tue Jan 13 06:50:54 2009
From: jgraham at opera.com (James Graham)
Date: Tue, 13 Jan 2009 15:50:54 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <4a30f5360901130618p19f27f25yfcce2b29c2ea02e5@mail.gmail.com>
References: <4a30f5360901130618p19f27f25yfcce2b29c2ea02e5@mail.gmail.com>
Message-ID: <496CAA4E.9030405@opera.com>

Giovanni Gentili wrote:

> Why we must restrict the use case to a single vocabulary
> or analyze all the possibile vocabularies?
> 
> I think it's be better to "generalize" the problem
> and find a unique solution for human/machine.

The issue when trying to abstract problems is that you can end up doing 
"architecture astronautics"; you concentrate on making generic ways to 
build solutions to weakly constrained problems without any attention to 
the details of those problems that make them unique. The solutions that 
are so produced often have the theoretical capacity to solve broad 
classes of problem, but are often found to be poor at solving any 
specific individual problem.

By looking at actual use cases we can hope to retain enough detail in 
the requirements that we satisfy at least some use cases well, rather 
than wasting out time building huge follies that serve no practical 
purpose to anyone.


From giovanni.gentili at gmail.com  Tue Jan 13 06:59:49 2009
From: giovanni.gentili at gmail.com (Giovanni Gentili)
Date: Tue, 13 Jan 2009 15:59:49 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <496CAA4E.9030405@opera.com>
References: <4a30f5360901130618p19f27f25yfcce2b29c2ea02e5@mail.gmail.com>
	<496CAA4E.9030405@opera.com>
Message-ID: <4a30f5360901130659j5e4da189l176271796f6d18d0@mail.gmail.com>

James Graham:
> The issue when trying to abstract problems is that you can end up doing
> "architecture astronautics"; you concentrate on making generic ways to build
> solutions to weakly constrained problems without any attention to the
> details of those problems that make them unique.

I think the right level, like in my proposal,
is greatly under "astronautics"
but no so low as "single vocabularies".

-- 
Giovanni Gentili


From jgraham at opera.com  Tue Jan 13 07:21:46 2009
From: jgraham at opera.com (James Graham)
Date: Tue, 13 Jan 2009 16:21:46 +0100
Subject: [whatwg] Fuzzbot (Firefox RDFa semantics processor)
In-Reply-To: <4a30f5360901130659j5e4da189l176271796f6d18d0@mail.gmail.com>
References: <4a30f5360901130618p19f27f25yfcce2b29c2ea02e5@mail.gmail.com>	<496CAA4E.9030405@opera.com>
	<4a30f5360901130659j5e4da189l176271796f6d18d0@mail.gmail.com>
Message-ID: <496CB18A.5030105@opera.com>

Giovanni Gentili wrote:
> James Graham:
>> The issue when trying to abstract problems is that you can end up doing
>> "architecture astronautics"; you concentrate on making generic ways to build
>> solutions to weakly constrained problems without any attention to the
>> details of those problems that make them unique.
> 
> I think the right level, like in my proposal,
> is greatly under "astronautics"
> but no so low as "single vocabularies".
> 

I rather disagree. How we interact with information depends 
fundamentally on the type of information. If the information is a set of 
geographical coordinates, for example, the set of useful interactions 
are rather different to those for a bibliographic entry. Trying to 
pretend that the two problems are just interchangeable instances of the 
same "semantically structured information" problem is likely to hide the 
important distinctions between the two problem domains.


From jonas at sicking.cc  Tue Jan 13 10:32:16 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 13 Jan 2009 10:32:16 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <op.uno4i3eg64w2qv@annevk-t60.oslo.opera.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<op.uno4i3eg64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <63df84f0901131032p36596935sc1e70e3e4c118ad9@mail.gmail.com>

On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren <annevk at opera.com> wrote:
> On Tue, 13 Jan 2009 13:44:22 +0100, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> I talked with Cameron a while ago about what the default behavior
>> should be for null. We couldn't find any functions that required that
>> null be treated as "null", but there are several examples of functions
>> that require that null be treated as the empty string.
>
> alert() requires it.

How so? I couldn't imagine how a site could depend on that.

That said, this did make me think about document.write, where we do
seem to display 'null' rather than empty string. So this might be an
exception.

> Besides that I believe we (Opera) specifically did it
> for methods here and there to be more compatible with Internet Explorer and
> make sites work better.

Do you know of any sites worked better because of the change? Or
indeed that were affected at all by the change?

/ Jonas


From annevk at opera.com  Tue Jan 13 11:28:42 2009
From: annevk at opera.com (Anne van Kesteren)
Date: Tue, 13 Jan 2009 20:28:42 +0100
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <63df84f0901131032p36596935sc1e70e3e4c118ad9@mail.gmail.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<op.uno4i3eg64w2qv@annevk-t60.oslo.opera.com>
	<63df84f0901131032p36596935sc1e70e3e4c118ad9@mail.gmail.com>
Message-ID: <op.unpm14i364w2qv@annevk-t60.oslo.opera.com>

On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking <jonas at sicking.cc> wrote:
> On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren <annevk at opera.com>  
> wrote:
>> alert() requires it.
>
> How so? I couldn't imagine how a site could depend on that.

Debugging, for one. You can't mean that you'd consider making alert(null)  
give a dialog that contains the empty string rather than "null".


>> Besides that I believe we (Opera) specifically did it
>> for methods here and there to be more compatible with Internet Explorer  
>> and make sites work better.
>
> Do you know of any sites worked better because of the change? Or
> indeed that were affected at all by the change?

No, sorry. I believe WebKit is doing it as well though for a number of  
methods/attributes, but it's been a while since I looked into this.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>


From shelleyp at burningbird.net  Tue Jan 13 12:54:15 2009
From: shelleyp at burningbird.net (Shelley Powers)
Date: Tue, 13 Jan 2009 14:54:15 -0600
Subject: [whatwg] My own take on the RDFa discussion
Message-ID: <496CFF77.3070606@burningbird.net>

Per discussion with Ian, I am posting a link to my take on the RDFa 
discussion to this list.

http://realtech.burningbird.net/semantic-web/semantic-markup/stop-justifying-rdfa

Thank you

Shelley Powers


From mjs at apple.com  Tue Jan 13 15:01:31 2009
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 13 Jan 2009 15:01:31 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <op.unpm14i364w2qv@annevk-t60.oslo.opera.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<op.uno4i3eg64w2qv@annevk-t60.oslo.opera.com>
	<63df84f0901131032p36596935sc1e70e3e4c118ad9@mail.gmail.com>
	<op.unpm14i364w2qv@annevk-t60.oslo.opera.com>
Message-ID: <DC16673F-68EF-4D0C-AFCD-6FE465609A24@apple.com>


On Jan 13, 2009, at 11:28 AM, Anne van Kesteren wrote:

> On Tue, 13 Jan 2009 19:32:16 +0100, Jonas Sicking <jonas at sicking.cc>  
> wrote:
>> On Tue, Jan 13, 2009 at 4:48 AM, Anne van Kesteren  
>> <annevk at opera.com> wrote:
>>> alert() requires it.
>>
>> How so? I couldn't imagine how a site could depend on that.
>
> Debugging, for one. You can't mean that you'd consider making  
> alert(null) give a dialog that contains the empty string rather than  
> "null".

Yeah, we definitely shouldn't change this for alert or document.write

>
>
>
>>> Besides that I believe we (Opera) specifically did it
>>> for methods here and there to be more compatible with Internet  
>>> Explorer and make sites work better.
>>
>> Do you know of any sites worked better because of the change? Or
>> indeed that were affected at all by the change?
>
> No, sorry. I believe WebKit is doing it as well though for a number  
> of methods/attributes, but it's been a while since I looked into this.

We have marked up some of the attributes and method parameters where  
the null value must be treated as "" instead of "null" with  
ConvertNullToNullString in our IDL. There are a number of method  
parameters that are not marked that way, but I'm not sure how many of  
these require the normal ECMAScript behavior and how many just haven't  
been changed.

Regards,
Maciej



From cam at mcc.id.au  Tue Jan 13 15:30:06 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 14 Jan 2009 10:30:06 +1100
Subject: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
In-Reply-To: <Pine.LNX.4.62.0901130930370.7181@hixie.dreamhostps.com>
References: <4B99A607-E778-43BF-B71D-8DFAC2BE022A@apple.com>
	<070C62C5-2AB7-4F22-A230-A7C43BCB8D59@apple.com>
	<9CAF2F9F-6811-4247-8C32-60AAC376E8C8@apple.com>
	<EE35A8FB-C86A-4AC8-AF85-61CA9FBF31F6@apple.com>
	<E2CC0E97-39B5-4126-86EC-AD801634DA7D@apple.com>
	<Pine.LNX.4.62.0901130930370.7181@hixie.dreamhostps.com>
Message-ID: <20090113233006.GD30640@arc.mcc.id.au>

Ian Hickson:
> > > For DOMStringMap, my intention was to not provide methods at all, and 
> > > only provide the JS-native mechanisms.

Maciej Stachowiak:
> > A bold choice, but I would not recommend it as the sole available 
> > mechanism.

Ian Hickson:
> See above for UndoManager, but for DOMStringMap I don't want to add any 
> other mechanisms, because they introduce name clashes. Right now the IDL 
> for DOMStringMap is:
> 
>    [NameCreator, NameDeleter, NameGetter, NameSetter]
>    interface DOMStringMap {};
> 
> It basically emulates a JS Object. It's intended only for JS. I don't see 
> why this is a bad idea.

At the moment, the interface is useful only for JS (and other languages
that support this kind of indexing).  For other languages, a
DOMStringMap object would appear to be a completely opaque object
without any means of interacting with it.  Given that this is basically
meant to be a shorthand for getting/setting attributes with particular
names, I would be happy with it not existing in other language bindings.
Web IDL doesn?t have a mechanism to state that an interface member or a
definition should only be included if the target language binding is a
particular one, though.

An alternative would be to put operations on the interface to act as the
getters/setters/etc., and use the [NoIndexingOperations] extended
attribute to indicate that these operations won?t correspond to
properties in language bindings such as ECMAScript.  That would then at
least make the interface useful for other languages.

-- 
Cameron McCormack ? http://mcc.id.au/


From cam at mcc.id.au  Tue Jan 13 15:37:08 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 14 Jan 2009 10:37:08 +1100
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
Message-ID: <20090113233707.GE30640@arc.mcc.id.au>

Jonas Sicking:
> I talked with Cameron a while ago about what the default behavior
> should be for null. We couldn't find any functions that required that
> null be treated as "null", but there are several examples of functions
> that require that null be treated as the empty string.

I began testing all attributes and operations with DOMString arguments
from a selection of specs for their behaviour wrt null and undefined:

  http://mcc.id.au/2009/01/string-handling/string-handling

Each pair of characters in the column for a browser is the behaviour for
null and undefined, respectively.  It?s nowhere near complete, though
you can see that there are some operations arguments and attributes that
stringify null to "null" (?S? in the column).

-- 
Cameron McCormack ? http://mcc.id.au/


From jonas at sicking.cc  Tue Jan 13 16:10:33 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 13 Jan 2009 16:10:33 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <20090113233707.GE30640@arc.mcc.id.au>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<20090113233707.GE30640@arc.mcc.id.au>
Message-ID: <63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>

On Tue, Jan 13, 2009 at 3:37 PM, Cameron McCormack <cam at mcc.id.au> wrote:
> Jonas Sicking:
>> I talked with Cameron a while ago about what the default behavior
>> should be for null. We couldn't find any functions that required that
>> null be treated as "null", but there are several examples of functions
>> that require that null be treated as the empty string.
>
> I began testing all attributes and operations with DOMString arguments
> from a selection of specs for their behaviour wrt null and undefined:
>
>  http://mcc.id.au/2009/01/string-handling/string-handling
>
> Each pair of characters in the column for a browser is the behaviour for
> null and undefined, respectively.  It's nowhere near complete, though
> you can see that there are some operations arguments and attributes that
> stringify null to "null" ("S" in the column).

So in the null column an "S" means that it's treated as "null", an "E"
as "", but what does "N" mean?

Yes, there are definitely a lot of "S"s in the null column for
non-firefox browsers. The question to me is if this is really needed
for webcompat though. Looking though our bug database I see no
indication of that, but that's not necessarily a proof.

If we were able to use "" as the default behavior for null then we
would be able to get away with much fewer exceptions (so far alert()
and and possibly write() has been found).

/ Jonas


From cam at mcc.id.au  Tue Jan 13 16:26:42 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 14 Jan 2009 11:26:42 +1100
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<20090113233707.GE30640@arc.mcc.id.au>
	<63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>
Message-ID: <20090114002642.GF30640@arc.mcc.id.au>

Jonas Sicking:
> So in the null column an "S" means that it's treated as "null", an "E"
> as "", but what does "N" mean?

"N" means that I was able to determine that null was treated as the
actual null value, rather than converted to a string.

> Yes, there are definitely a lot of "S"s in the null column for
> non-firefox browsers. The question to me is if this is really needed
> for webcompat though. Looking though our bug database I see no
> indication of that, but that's not necessarily a proof.
> 
> If we were able to use "" as the default behavior for null then we
> would be able to get away with much fewer exceptions (so far alert()
> and and possibly write() has been found).

OK.  So what is more important for choosing the default: fewer
exceptions (and thus fewer [Null=?] things polluting the IDL),
consistency with the default stringification behaviour of ECMAScript,
or avoiding the somewhat counterintuitive default behaviour of
converting a valid value of the type to a different value of that type?

-- 
Cameron McCormack ? http://mcc.id.au/


From jonas at sicking.cc  Tue Jan 13 16:42:23 2009
From: jonas at sicking.cc (Jonas Sicking)
Date: Tue, 13 Jan 2009 16:42:23 -0800
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <20090114002642.GF30640@arc.mcc.id.au>
References: <6811E688-7A28-4034-B874-1F12E968CDFC@apple.com>
	<op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<20090113233707.GE30640@arc.mcc.id.au>
	<63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>
	<20090114002642.GF30640@arc.mcc.id.au>
Message-ID: <63df84f0901131642k7c26688eh13dd8182fb03743e@mail.gmail.com>

On Tue, Jan 13, 2009 at 4:26 PM, Cameron McCormack <cam at mcc.id.au> wrote:
> Jonas Sicking:
>> So in the null column an "S" means that it's treated as "null", an "E"
>> as "", but what does "N" mean?
>
> "N" means that I was able to determine that null was treated as the
> actual null value, rather than converted to a string.

So it behaves different from passing in an empty string? For some
functions this surprises me, such as for the namespace parameter for
getAttributeNS, I would think that we there treat "" the same as null.

>> Yes, there are definitely a lot of "S"s in the null column for
>> non-firefox browsers. The question to me is if this is really needed
>> for webcompat though. Looking though our bug database I see no
>> indication of that, but that's not necessarily a proof.
>>
>> If we were able to use "" as the default behavior for null then we
>> would be able to get away with much fewer exceptions (so far alert()
>> and and possibly write() has been found).
>
> OK.  So what is more important for choosing the default: fewer
> exceptions (and thus fewer [Null=?] things polluting the IDL),
> consistency with the default stringification behaviour of ECMAScript,
> or avoiding the somewhat counterintuitive default behaviour of
> converting a valid value of the type to a different value of that type?

"converting a valid value of the type to a different value of that
type", which values exactly?

I think another factor, that you haven't mentioned, that is very
important is web compatibility. But beyond that I think I would rate
fewer exceptions highest.

/ Jonas


From cam at mcc.id.au  Tue Jan 13 16:53:10 2009
From: cam at mcc.id.au (Cameron McCormack)
Date: Wed, 14 Jan 2009 11:53:10 +1100
Subject: [whatwg] DOM Storage feedback
In-Reply-To: <63df84f0901131642k7c26688eh13dd8182fb03743e@mail.gmail.com>
References: <op.t9e3sshn64w2qv@annevk-t60.oslo.opera.com>
	<A26D19B7-4813-4F6A-B3CC-1E785A47A04E@apple.com>
	<Pine.LNX.4.62.0804272254580.15946@hixie.dreamhostps.com>
	<E5A7DAB7-AB42-44F6-A81B-6C43CD7246BA@apple.com>
	<Pine.LNX.4.62.0901130940230.7181@hixie.dreamhostps.com>
	<63df84f0901130444rbbd679dtd7e01a1d600489c3@mail.gmail.com>
	<20090113233707.GE30640@arc.mcc.id.au>
	<63df84f0901131610u75b81d2arbe245b7cbb44fd2a@mail.gmail.com>
	<20090114002642.GF30640@arc.mcc.id.au>
	<63df84f0901131642k7c26688eh13dd8182fb03743e@mail.gmail.com>
Message-ID: <20090114005310.GG30640@arc.mcc.id.au>

Jonas Sicking:
> So it behaves different from passing in an empty string? For some
> functions this surprises me, such as for the namespace parameter for
> getAttributeNS, I would think that we there treat "" the same as null.

Not necessarily, but I agree that would be a better thing to report.
I?ll rejig the tests to get that information.

Cameron McCormack:
> > OK.  So what is more important for choosing the default: fewer
> > exceptions (and thus fewer [Null=?] things polluting the IDL),
> > consistency with the default stringification behaviour of ECMAScript,
> > or avoiding the somewhat counterintuitive default behaviour of
> > converting a valid value of the type to a different value of that type?

> "converting a valid value of the type to a different value of that
> type", which values exactly?

null.  It feels slightly strange to me to treat null as a ?second class
value? by default.  But I?ll get over it. :-)

It may actually be indicative of a need for two distinct types: strings
(i.e., possibly empty sequences of characters) and strings-or-null.  But
I don?t know if it?s worth rewriting everything in this way.

> I think another factor, that you haven't mentioned, that is very
> important is web compatibility. But beyond that I think I would rate
> fewer exceptions highest.

Well, I assume that writers of specs that document already-implemented
interfaces will choose the appropriate [Null] annotation (or lack of it)
for web compatibility.  Which to choose as the default is orthogonal, I
think.

-- 
Cameron McCormack ? http://mcc.id.au/


From ian at hixie.ch  Tue Jan 13 17:08:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 01:08:26 +0000 (UTC)
Subject: [whatwg] WebIDL vs HTML5 storage changes - delete behavior
In-Reply-To: <20090113233006.GD30640@arc.mcc.id.au>
References: <4B99A607-E778-43BF-B71D-8DFAC2BE022A@apple.com>
	<070C62C5-2AB7-4F22-A230-A7C43BCB8D59@apple.com>
	<9CAF2F9F-6811-4247-8C32-60AAC376E8C8@apple.com>
	<EE35A8FB-C86A-4AC8-AF85-61CA9FBF31F6@apple.com>
	<E2CC0E97-39B5-4126-86EC-AD801634DA7D@apple.com>
	<Pine.LNX.4.62.0901130930370.7181@hixie.dreamhostps.com>
	<20090113233006.GD30640@arc.mcc.id.au>
Message-ID: <Pine.LNX.4.62.0901140105450.29785@hixie.dreamhostps.com>

On Wed, 14 Jan 2009, Cameron McCormack wrote:
> > 
> >    [NameCreator, NameDeleter, NameGetter, NameSetter]
> >    interface DOMStringMap {};
> 
> At the moment, the interface is useful only for JS (and other languages 
> that support this kind of indexing).  For other languages, a 
> DOMStringMap object would appear to be a completely opaque object 
> without any means of interacting with it.  Given that this is basically 
> meant to be a shorthand for getting/setting attributes with particular 
> names, I would be happy with it not existing in other language bindings. 
> Web IDL doesn?t have a mechanism to state that an interface member or 
> a definition should only be included if the target language binding is a 
> particular one, though.
> 
> An alternative would be to put operations on the interface to act as the 
> getters/setters/etc., and use the [NoIndexingOperations] extended 
> attribute to indicate that these operations won?t correspond to 
> properties in language bindings such as ECMAScript.  That would then at 
> least make the interface useful for other languages.

What I would like to be able to say is: "This is how it works in JS. If 
you are implementing this in another language binding, contact me and 
we'll come up with a solution for that language."

I don't want this to only work in JS, I just haven't designed the API for 
the other languages. And I don't want to introduce a suboptimal design -- 
e.g. the above IDL would be meaningless for Perl, where objects don't have 
a concept of name getters, etc. But for Perl what we'd want is to expose a 
tied hash, which is the equivalent of what this is in JS. But we don't yet 
have WebIDL magic for Perl, so I can't say that yet.

Does that make sense?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Tue Jan 13 18:41:03 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 02:41:03 +0000 (UTC)
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <c9e12660808121102j36d656fcpa19e3eea187ab3cc@mail.gmail.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<a9699fd20808041517u45fefc60t42c65f2c2a5a5616@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<3B0990F66B884008A2EE6AB89CB9AE83@POCZTOWIEC>
	<c9e12660808121100h3b40d129kc6df56686368824e@mail.gmail.com>
	<c9e12660808121102j36d656fcpa19e3eea187ab3cc@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0901140240000.7181@hixie.dreamhostps.com>


There were a number of e-mails on this thread regarding how Collections 
and other interfaces worked with respect to properties being exposed. I 
have now updated the HTML5 spec to take into account the new features in 
WebIDL that expose these properties. Please let me know if I missed one.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Tue Jan 13 18:59:47 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 02:59:47 +0000 (UTC)
Subject: [whatwg] WindowHTML Option() constructor
In-Reply-To: <op.ujralog964w2qv@annevk-t60.oslo.opera.com>
References: <op.tijhaiv0aw9dld@id-c0020>
	<Pine.LNX.4.62.0810280952270.1237@hixie.dreamhostps.com>
	<op.ujralog964w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0901140259360.7181@hixie.dreamhostps.com>

On Tue, 28 Oct 2008, Anne van Kesteren wrote:
> On Tue, 28 Oct 2008 02:52:36 -0700, Ian Hickson <ian at hixie.ch> wrote:
> > On Sun, 5 Nov 2006, Anne van Kesteren wrote:
> > > 
> > > The Option() constructor takes four arguments: 'Option(in DOMString
> > > name, in DOMString value, in boolean defaultSelected, in boolean
> > > selected)' is the complete version of it.
> > 
> > Fixed.
> 
> The IDL uses Constructor() but should use NamedConstructor=Option() 
> instead. (See e.g. HTMLImageElement for how it should be done.)

Apparently I fixed this at some point.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Wed Jan 14 00:56:26 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 08:56:26 +0000 (UTC)
Subject: [whatwg] number-related feedback
In-Reply-To: <20090101003608.GA7312@arc.mcc.id.au>
References: <Pine.LNX.4.62.0803231934330.12521@hixie.dreamhostps.com>
	<247EF56B-9175-4C96-93C1-7428BA0BDC8C@crissov.de>
	<Pine.LNX.4.62.0808212334190.14795@hixie.dreamhostps.com>
	<1219382078.14384.34.camel@betamax.arc.net.au>
	<Pine.LNX.4.62.0812291024050.24109@hixie.dreamhostps.com>
	<63df84f0812301817w2d46b333y9aad142a6df2a541@mail.gmail.com>
	<63df84f0812301823y7f0cac82q55f4eb377f5db57f@mail.gmail.com>
	<Pine.LNX.4.62.0812310357450.25317@hixie.dreamhostps.com>
	<63df84f0812310523l61337503xb2b061ed69079099@mail.gmail.com>
	<Pine.LNX.4.62.0812312204400.25317@hixie.dreamhostps.com>
	<20090101003608.GA7312@arc.mcc.id.au>
Message-ID: <Pine.LNX.4.62.0901140856020.7181@hixie.dreamhostps.com>

On Thu, 1 Jan 2009, Cameron McCormack wrote:
> 
> Ian Hickson:
> > The UA would set a limit on the value it accepts for maxlength="", and 
> > then cap the result at that, preventing someone from entering more than 
> > 4GB (or 2GB, or 4TB, or whatever limit the UA has). Does that answer your 
> > question? In practice I would expect other limitations to come into play 
> > long before a test for this limit could be triggered.
> 
> I don?t think it does answer the question, since you need to know what
> happens if you do:
> 
>   e.setAttribute('maxlength', '5000000000');
>   alert(e.maxlength)
> 
> The text currently in the spec isn?t clear:
> 
>   If a reflecting DOM attribute is an unsigned integer type (unsigned
>   long) then, on getting, the content attribute must be parsed according
>   to rules for parsing non-negative integers, and if that is successful,
>   the resulting value must be returned. If, on the other hand, it fails,
>   or if the attribute is absent, the default value must be returned
>   instead, or 0 if there is no default value.
> 
> The ?rules for parsing non-negative integers? algorithm can return any
> non-negative integer.  Web IDL doesn?t define what to do if a spec
> defines an operation to return a value that is not a member of its
> return type.  I?d classify that as a bug in the description of
> reflecting DOM attributes.
> 
> I suggest to reword that paragraph to something like the following:
> 
>   If a reflecting DOM attribute is an unsigned integer type (unsigned
>   long) then, on getting, the content attribute must be parsed according
>   to rules for parsing non-negative integers, and if that successfully
>   returns a value in the range of an unsigned long, that resulting value
>   must be returned. If, on the other hand, it fails, returns an out of
>   range value, or if the attribute is absent, the default value must be
>   returned instead, or 0 if there is no default value.
> 
> Similar wording would be needed for other paragraphs in this section.

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Wed Jan 14 00:57:05 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 08:57:05 +0000 (UTC)
Subject: [whatwg] Return type of HTMLCanvasElement::getContext()
In-Reply-To: <20090101085757.GA11964@arc.mcc.id.au>
References: <20090101085757.GA11964@arc.mcc.id.au>
Message-ID: <Pine.LNX.4.62.0901140857021.7181@hixie.dreamhostps.com>

On Thu, 1 Jan 2009, Cameron McCormack wrote:
>
> I think the return type of HTMLCanvasElement::getContext() should go 
> back to being an object instead of any.  I don?t see any situation 
> where that method would usefully return a non-object value.  I suggest 
> just using ?Object? instead of ?DOMObject?, too.  DOMObject is 
> just a typedef for Object in DOM Core.

Done.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Wed Jan 14 01:00:01 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 09:00:01 +0000 (UTC)
Subject: [whatwg] Window::showModalDialog() missing [Variadic]
In-Reply-To: <20090101091406.GC11964@arc.mcc.id.au>
References: <20090101091406.GC11964@arc.mcc.id.au>
Message-ID: <Pine.LNX.4.62.0901140857560.7181@hixie.dreamhostps.com>

On Thu, 1 Jan 2009, Cameron McCormack wrote:
>
> The >1 argument version of Window::showModalDialog() is missing a
> [Variadic] on the second argument:
> 
>   interface Window {
>     ?
>     any showModalDialog(in DOMString url);
>     any showModalDialog(in DOMString url, in any arguments);
>     ?
>   };
> 
> Since no arguments need be passed for those designated with [Variadic],
> the two operations could just be combined into one:
> 
>   interface Window {
>     ?
>     any showModalDialog(in DOMString url, [Variadic] in any arguments);
>     ?
>   };

Actually only one argument can be passed there. I've renamed the parameter 
for clarity.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Wed Jan 14 01:11:23 2009
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Jan 2009 09:11:23 +0000 (UTC)
Subject: [whatwg] Web Workers: minor issues
In-Reply-To: <op.und2mwc064w2qv@annevk-t60.oslo.opera.com>
References: <op.und2mwc064w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0901140900480.7181@hixie.dreamhostps.com>

On Wed, 7 Jan 2009, Anne van Kesteren wrote:
>
> showNotification is no longer part of HTML5.

Fixed.


> The SharedWorker IDL block uses <code>. That should probably be <span>.

Fixed.


> Why is everything a NoInterfaceObject? Doesn't that mean that you can no 
> longer prototype them?

I've updated all the IDL to make more sense. Thanks.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From stewart.brodie at antplc.com  Wed Jan 14 05:16:42 2009
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Wed, 14 Jan 2009 13:16:42 +0000
Subject: [whatwg] getElementsByClassName case sensitivity
In-Reply-To: <op.unoxsz1h64w2qv@annevk-t60.oslo.opera.com>
References: <AA7EA371-4768-4D80-8F20-D2B7D1A1E42D@gmail.com> 
	<Pine.LNX.4.62.0807250946040.10853@hixie.dreamhostps.com> 
	<2717a9c1e4e975487af6cb43ac4670d45b2dd91c@localhost> 
	<op.unn4tpps64w2qv@annevk-t60.oslo.opera.com> 
	<47b6c05a5d4e2b26b3218bc1638f1210d3d357e5@localhost> 
	<op.unoxiuf464w2qv@annevk-t60.oslo.opera.com> 
	<op.unoxsz1h64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <7fdd370ee1317b5215947ebe3b57848d7d9f31cf@localhost>

Anne van Kesteren <annevk at opera.com> wrote:

> On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren <annevk at opera.com>
> wrote:
> > Since my initial e-mail did not seem to have done it, could you please
> > take a look at the source code of the respective test and tell me if you
> > see a problem there?
> >
> >    http://tc.labs.opera.com/apis/getElementsByClassName/014.htm
> >
> > To be perfectly clear, there is no discrepancy between CSS handling and
> > the getElementsByClassName method and the test is testing that there is
> > not.
> 
> Wow, epic fail. I missed it should match two elements. The test is indeed
> out of date.
> 
> * updates the test now.

Excellent - thanks!


-- 
Stewart Brodie
Software Engineer
ANT Software Limited


From ian at hixie.ch  Wed Jan 14 18:25:42 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 15 Jan 2009 02:25:42 +0000 (UTC)
Subject: [whatwg] pushState
In-Reply-To: <op.ufje3f2c64w2qv@annevk-t60.oslo.opera.com>
References: <4889BFDF.7010003@sicking.cc>
	<Pine.LNX.4.62.0807251847070.10848@hixie.dreamhostps.com>
	<488A496E.70604@sicking.cc>
	<Pine.LNX.4.62.0807252154320.10848@hixie.dreamhostps.com>
	<488A6154.9080701@sicking.cc>
	<Pine.LNX.4.62.0807252334590.10848@hixie.dreamhostps.com>
	<488ABBDC.5030308@sicking.cc> <488C7C25.7070003@sicking.cc>
	<Pine.LNX.4.62.0807282229580.10848@hixie.dreamhostps.com>
	<488F57E4.9070508@sicking.cc>
	<Pine.LNX.4.62.0807292009520.30692@hixie.dreamhostps.com>
	<4896195C.2040101@sicking.cc>
	<op.ufje3f2c64w2qv@annevk-t60.oslo.opera.com>
Message-ID: <Pine.LNX.4.62.0901150139490.7181@hixie.dreamhostps.com>

On Fri, 25 Jul 2008, Jonas Sicking wrote:
>
> So to back up. There are a few things that are important to me:
> 
> 1. The session history (SH) entries created in this way should act
>    as much like normal SH entries as possible to the user.
>    I.e. the user doesn't care if clicking what looks like a link
>    results in a navigation or a .pushState call.
> 2. That this API allows pages to be written that survives a browser
>    restart.
>    This is to prevent data loss in case of crash, and to increase
>    chances that users install security updates which require restart
>    as soon as possible.
> 3. That the API encourages bug-free pages. I.e. pages that use the API
>    'correctly'.
> 
> Just 1 in itself means that we can't just kill SH entries just because
> the Document they were created from goes away from fastback. If I browse
> away from a gmail and see 5 pages in my SH list then I would be very
> disappointed if those 5 pages just disappeared because I happened to be
> browsing around in another window which ate up the fastback cache.
> 
> Similarly, a mobile device might not have a fastback cache at all. It
> would look very strange if while i'm staying on the gmail site i'm able
> to go 'back' to what to me looks like various different pages. But as
> soon as i go to some other site, I loose all those pages and can only go
> back directly to the first gmail page.
> 
> So we must definitely store the pushed SH data in such a way that if the
> Document is recreated the data survives.
> 
> This applies whether the URL of my browser changes or not while I'm
> doing this browsing. The rendering changing is more important than the
> URL changing for a user.
> 
> 
> So what I think we should do is to enforce that 'data' is a JSON
> serializable object. When a Document is destroyed (due to eviction from
> the fastback cache or due to not being cachable) we don't touch the SH
> entries associated with that document.

Ok. I've used the new "structured clone" concept to sanitise the data and 
make a copy instead of storing the actual object. This enables us to keep 
them around even when the Document is evicted.

One thing I had to change is that now if you go from state 1 to state 3, 
state 2 is no longer popped. You can move discontinuously through the 
states.


> When entering a SH state for which a Document has been destroyed, we
> load the URL associated with that SH entry. After the 'load' event for
> the Document has fired, and if a data object was provided in the
> pushState call for the SH entry, we fire a PopStateEvent event
> containing the data stored for the object.
> 
> The same thing happens if the user clicks the reload button while on an
> SH entry created using pushState. The URL for that entry is loaded and
> after the 'load' event has fired, if a data object was provided during
> the pushState call, a PopStateEvent is fired with that data.

The timing here is difficult. What should happen if while the page is 
loading, the user navigates to a link with a fragment identifier, or 
invokes pushState, or navigates to another SH entry with a state object?

I'll see what I can come up with. It may be that I'll just delay all 
popstate and hashchanged events until the 'load' event has fired, and then 
I'll fire both for the current state.


> To minimize the difference between when a SH entry is recovered from the 
> fastback cache, compared to when the document is reparsed, the Location 
> object should be changed to reflect the new URL whenever pushState is 
> called with a url. The advantage of changing the Location object is that 
> this makes the page behave the same no matter of if it has been reloaded 
> or not. Setting the Location objects value will cause reloading vs. 
> scrolling vs. do nothing in the same cases. Similarly reading the 
> Location will return the same thing no matter of if there has been a 
> reload or not.

I just found that I wasn't even updating the Location for fragment 
identifier changes. Oops. I'll fix that and give the behavior you describe 
when I fix bug 6437.

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=6437

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From ian at hixie.ch  Thu Jan 15 00:11:33 2009
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 15 Jan 2009 08:11:33 +0000 (UTC)
Subject: [whatwg] E4X and attribute values
In-Reply-To: <op.tl9nh62a4suneb@g5.local>
References: <07435492-332F-4525-B692-03A4B44680FD@iki.fi>
	<op.tl9nh62a4suneb@g5.local>
Message-ID: <Pine.LNX.4.62.0901150753040.7181@hixie.dreamhostps.com>

On Tue, 16 Jan 2007, Henri Sivonen wrote:
>
> Is E4X allowed in event handler attribute values and in javascript: 
> URIs? If yes, how can a UA know whether the E4X parse mode should be 
> used?
> 
> (It seems to me that it would make sense not to allow E4X in those cases 
> and require the script snippets to call into E4X scripts included using 
> the <script> element. But I don't really know what Firefox does here.)

On Tue, 16 Jan 2007, Kornel Lesinski wrote:
> 
> This can be explictly stated using Content-Script-Type HTTP header/meta and
> Mozilla's MIME type parameter:
> <meta http-equiv="Content-Script-Type" content="text/javascript; e4x=1" />
> 
> http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6
> http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.2.1
> 
> However since the e4x type parameter seems to be only affecting parsing 
> of comments and CDATA inside <script>, it's irrelevant for attributes, 
> so I think it shouldn't be required and E4X should work in 
> attributes/bookmarklets by default.

There is currently no mechanism in HTML5 to control the langueg of an 
event listener. I'm not really sure how to provide this extensibility -- 
the HTML4 mechanism is very coarse (it just controls the language of all 
event handler attributes), but I can't see any efficient way to introduce 
a more fine-grained mechanism.

My recommendation would be to ensure that extensions to JavaScript, and 
new languages in general, be written to either be backwards-compatible, or 
be written with a signature at the front. This would allow authors to 
upgrade scripts independently of referencing mechanisms (e.g. allowing 
sites to upgrade to newer language features without changing the <script> 
block that refers to them).

In any case, as Kornel says, it seems like this is a non-issue for the 
original problem raised, namely of E4X in attributes.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'


From lists.whatwg at stakface.com  Thu Jan 15 07:48:30 2009
From: lists.whatwg at stakface.com (Kartikaya Gupta)
Date: Thu, 15 Jan 2009 15:48:30 +0000
Subject: [whatwg] When do scripts execute? (4.3.1)
Message-ID: <20090115154846.C88A714D983@looneymail-mx2.g.dreamhost.com>

I have a question about when scripts execute. From my reading of section 4.3.1 it seems like if script elements are created and added to the DOM via DOM operations, then they should NOT be marked as parser-inserted, and should get run immediately (assuming no defer/async stuff). However, a page that I constructed to test this (below) fails in FF, Opera, and Safari (didn't test IE). Am I misreading the spec, or does it not accurately reflect current behavior? I found [1] after poking through the archives a bit, and it's somewhat related, but doesn't address this issue directly.

<div id="r">NOTRUN</div>
<script type="text/javascript">
 var sn = document.createElement('script');
 sn.setAttribute( 'type', 'text/javascript' );
 sn.appendChild( document.createTextNode( 'document.getElementById("r").firstChild.data = "PASS";' ) );
 document.body.appendChild( sn );        // this runs the script and sets r's text to PASS (verifiable by alert)

 sn = document.createElement( 'script' );
 sn.setAttribute( 'type', 'text/javascript' );
 document.body.appendChild( sn );        // this *should* run an empty script block and do nothing
 // the next line should have no effect since the script already ran
 sn.appendChild( document.createTextNode( 'document.getElementById("r").firstChild.data = "FAIL";' ) );
 // here r's text is FAIL. why?
</script>

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011561.html

Cheers,
kats


From bzbarsky at MIT.EDU  Thu Jan 15 08:28:10 2009
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 15 Jan 2009 11:28:10 -0500
Subject: [whatwg] When do scripts execute? (4.3.1)
In-Reply-To: <20090115154846.C88A714D983@looneymail-mx2.g.dreamhost.com>
References: <20090115154846.C88A714D983@looneymail-mx2.g.dreamhost.com>
Message-ID: <496F641A.6030002@mit.edu>

Kartikaya Gupta wrote:
>  sn = document.createElement( 'script' );
>  sn.setAttribute( 'type', 'text/javascript' );
>  document.body.appendChild( sn );        // this *should* run an empty script block and do nothing

That looks like a bug in the spec to me.  Empty scripts with no @src are 
not executed when inserted into the DOM, and are executed if they ever 
become nonempty or have their src set.

-Boris



From dhtmlkitchen at gmail.com  Thu Jan 15 11:27:26 2009
From: dhtmlkitchen at gmail.com (Garrett Smith)
Date: Thu, 15 Jan 2009 11:27:26 -0800
Subject: [whatwg] HTML 5 : Misconceptions Documented
In-Reply-To: <Pine.LNX.4.62.0901142200580.29785@hixie.dreamhostps.com>
References: <c9e12660807292333v2e0d7e6eu115de715a1043941@mail.gmail.com>
	<c9e12660808042303q21d19484nfb91e6f92bd636c3@mail.gmail.com>
	<a9699fd20808051602q1da0968egd5ba3f36101c97a8@mail.gmail.com>
	<c9e12660808052348o6974396dma11cbc3773b4329a@mail.gmail.com>
	<3B0990F66B884008A2EE6AB89CB9AE83@POCZTOWIEC>
	<c9e12660808121100h3b40d129kc6df56686368824e@mail.gmail.com>
	<c9e12660808121102j36d656fcpa19e3eea187ab3cc@mail.gmail.com>
	<Pine.LNX.4.62.0901140240000.7181@hixie.dreamhostps.com>
	<c9e12660901131917s32e6ff39pb9538892f4729213@mail.gmail.com>
	<Pine.LNX.4.62.0901142200580.29785@hixie.dreamhostps.com>
Message-ID: <c9e12660901151127h3b00dc58i26a2b66f7d1355b9@mail.gmail.com>

(back on list)

On Wed, Jan 14, 2009 at 2:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 13 Jan 2009, Garrett Smith wrote:
>> On Tue, Jan 13, 2009 at 6:41 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >
>> > There were a number of e-mails on this thread regarding how Collections
>>
>> Which thread are referring to?
>
> The one entitled "HTML 5 : Misconceptions Documented".
>

Sorry.

>
>> > and other interfaces worked with respect to properties being exposed.
>> > I have now updated the HTML5 spec to take into account the new
>> > features in WebIDL that expose these properties. Please let me know if
>> > I missed one.
>>

I see. It looks like you've mimicked current methods of HTMLCollection
- item - and - namedItem - on the form. These methods delegate to
same-named methods on the elements collection.

I see several paragraphs that describe how HTMLFormElement has
same-named methods that delegate to HTMLCollection.

http://www.whatwg.org/specs/web-apps/current-work/#htmlformelement

The specification does not say that HTMLFormElement implement HTMLCollection.

The spec has defined new behavior, "past names map":-

| Each form element has a mapping of names to elements called the
| *past names map*. It is us