date:20081118


Robert O'Rourke wrote:

Martin McEvoy wrote:

Lachlan Hunt wrote:

Martin McEvoy wrote:
 From the "real world" found here: 
http://nfegen.wordpress.com/2008/03/28/micrordformats/


href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


In any case, if there was a real use case for such a relationship, 
then it rel="reply-to" would seem to be more appropriate.  It's 
meaning would then be roughly analogous to that of the In-Reply-To 
email header field. 

That was  a good example of how Murky @rel is compared to @rev

href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


would be 
 
is in reply to the referencing document surely?


Thanks



Hi Martin, hope you're well :)


Hello Rob, nice to hear from you, yes I am well :-)



I don't chirp up that often on this list but I have to agree that @rev 
isn't much of a loss. Perhaps for the above example rel="source" or 
rel="muse" would be semantically valid as a reply could be said to be 
inspired by the thing it's replying to... maybe that's a bad example.


No Not that bad rel=muse is near the mark, but the author of the page I 
am referencing may not give me inspiration, I just want to reply to 
someone, it may be rhetorical, or insulting?


XFN rel values like "muse" are about how you think they would relate to 
you, not about how you would relate to them eg:


http://sanchothefat.com/"; rel="muse">Robert O'Rourke

I would be saying that  would describe itself 
a muse of the referencing document?


by abandoning @rev you are denying the author the ability to express 
inverse relationships, the ability to say that I have some explicit 
relationship to a thing


To follow mailing list standards there are replies to the Original 
Poster or OP so maybe you could use rel="op". Replies via blog posts 
are pretty much the same as an email reply, just in a different 
context. Maybe it's not ideal but @rev can be really confusing 
sometimes as demonstrated by the evidence.


@rev => how "this" relates to "that"

@rel => how "that" relates to "this"




Rob


Thanks

--
Martin McEvoy

http://weborganics.co.uk/

Re: [whatwg] Workers feedback

2008-11-18 Thread Alexey Proskuryakov

on 18.11.2008 06:43, Ian Hickson at [EMAIL PROTECTED] wrote:

>> I'd be more that happy with a separate interface if the objects actually
>> behaved differently. One example of a good reason to have separate
>> interfaces was recently proposed here: shared workers should outlive
>> their creators. This is the sort of difference that would make having a
>> separate API reasonable, in my opinion.
> 
> You don't think that the way that a handle to a shared worker can be
> obtained dynamically without contact with the original creator is enough
> of a difference?

I think that this is a difference in a single function (namely, constructor)
behavior. One constructor can create named workers, and another can create
unnamed ("null-named") workers, which doesn't mean that they need to create
different kinds of objects.

But I've already said it before, so this is not new feedback.

> The complication here seems to be in the way you are implementing this.
> Port entangling should be atomic across threads -- when you are sending a
> port over another channel, you should block both threads, create the new
> object, 

Sorry if this looks like I'm just trying to be difficult, but you already
have a chance to deadlock here. If the blocked thread was inside malloc(),
then attempting to allocate memory in the main thread will freeze the
application.

This is very much an implementation concern, and in this particular case, it
is easily resolvable (you could allocate memory before locking).
Unfortunately, implementation bugs like this are notoriously hard to find
with testing, as they may be triggered by very specific usage scenarios. So,
even having a working implementation doesn't really mean that a spec written
in this manner is implementable, paradoxically.

> update the information,

I'm not sure what you mean here - certainly not hunting down all references
to the old entangled port that may be anywhere, or fixing all results of
calculations that involved its address? Yet, this is necessary if you are
blocking threads at arbitrary moments.

Again, an implementation concern, but the spec as it is talks about
algorithms, and not observable effects, and it is not clear to me what the
observable effects should be in cases where synchronous communication is
specced.

> shunt all pending messages over, and then
> resume the threads. If you implement the actual IPC using, say, a Unix
> socket, then you can just pass the actual socket along and do the same
> thing without blocking.

This is an interesting point. I do not know enough about how Unix domain
sockets are passed around, but since they the laws of nature are the same
for them, it's either that:
- my FUD is unbased, and it is in fact possible to implement the behavior;
- or semantics are very different for sockets. Some guesses are that queues
may be strictly limited in size, message delivery may not be guaranteed, or
that it is possible for client code to irrepairably deadlock processes with
them - something that JS developers obviously shouldn't be able to do.

I do not know which of the options is correct, but if the spec talked in
terms of message passing, it would have been more easily verifiable.

>>> For example, any method that entangles two ports blocks until both
>>> threads are synchronised and entangled.
>> 
>> This will cause deadlocks - if portB' is sent to the first thread as
>> portB'' in the above scheme, the lock will not let synchronization ever
>> finish.
> 
> Could you elaborate on this? I'm not sure I follow what you mean. If you
> mean that two ports in two threads are posted to each other's threads at
> the same time, 

Yes, this is what I'm talking about.

> then deadlock would only happen in a naive implementation
> that didn't keep pumping its message queue while waiting for a response
> from the other thread. Instead what you would want to do is to ask for a
> semaphore to communicate with the other thread, and if you don't get it,
> see if anyone wants to communicate with you, and if they do, let them do
> whatever they want, and then try again.

Designs like this are quite prone to all sorts of crazy problems, too. As a
simple example, the port waiting to be entangled may be sent further on, if
you let them "do whatever they want".

> I'm certainly open to changing the algorithms around if a better solution
> exists in a manner that gets the same behavior. I'm certainly no expert on
> the topic (as I'm sure the above responses have shown).

Since the spec is written in form of algorithms, and relies on a number of
arguable implicit assumptions on the implementation of their steps, it is
hard to process or verify the algorithms. In my opinion (I'm not claiming
expertise either!), a message passing design would be much clearer.

There are lots of discussions about designing multi-threaded algorithms on
the net, one I liked quite a bit recently is
 - it
presents the do's

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers


Joshua Cranmer wrote:

Mike wrote:
The benefits? Oh I don't know.. a markup language that supports the 
transfer protocol it runs on?!
Who says you have to serve HTML over HTTP? I see it served via email 
(and newsgroups), local filesystems, and FTP on a regular basis. 
Indeed, making HTML depend on HTTP-specific features sounds like A Bad 
Idea™ (and if you retort XMLHTTPRequest, let me point out that I 
personally would have objected to injecting HTTP specifics into that 
interface, had I been around during the design phases).


To follow your arguments to the logical conclusion, HTML would have to 
have special attributes to deal with circumstances within email 
messages, specific attributes to handle certain filesystem-specific 
abilities, or quirks of the FTP protocol. I think you'll find such a 
position untenable; ask yourself then, why limit it to HTTP?


I wouldn't limit it to that, but I don't have the time or inclination to 
investigate other applicable protocols that suffer equally poor support 
in HTML. If you can evidence this the same way I have for Accept headers 
in HTTP; let me know - I'll champion that too if it makes you feel 
better! :)


Regards,
Mike

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

2008-11-18 Thread Joshua Cranmer


Mike wrote:
The benefits? Oh I don't know.. a markup language that supports the 
transfer protocol it runs on?!
Who says you have to serve HTML over HTTP? I see it served via email 
(and newsgroups), local filesystems, and FTP on a regular basis. Indeed, 
making HTML depend on HTTP-specific features sounds like A Bad Idea™ 
(and if you retort XMLHTTPRequest, let me point out that I personally 
would have objected to injecting HTTP specifics into that interface, had 
I been around during the design phases).


To follow your arguments to the logical conclusion, HTML would have to 
have special attributes to deal with circumstances within email 
messages, specific attributes to handle certain filesystem-specific 
abilities, or quirks of the FTP protocol. I think you'll find such a 
position untenable; ask yourself then, why limit it to HTTP?


--
Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald E. Knuth

Re: [whatwg] Absent rev?

2008-11-18 Thread Robert O'Rourke

Martin McEvoy wrote:

Lachlan Hunt wrote:

Martin McEvoy wrote:
From the "real world" found here:
http://nfegen.wordpress.com/2008/03/28/micrordformats/

href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html";
title="Link to Mark Birbeck blog post">‘So how about using RDFa in
Microformats?’

In any case, if there was a real use case for such a relationship,
then it rel="reply-to" would seem to be more appropriate. It's
meaning would then be roughly analogous to that of the In-Reply-To
email header field.

That was a good example of how Murky @rel is compared to @rev

href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html";
title="Link to Mark Birbeck blog post">‘So how about using RDFa in
Microformats?’

would be

is in reply to the referencing document surely?

Thanks

Hi Martin, hope you're well :)

I don't chirp up that often on this list but I have to agree that @rev
isn't much of a loss. Perhaps for the above example rel="source" or
rel="muse" would be semantically valid as a reply could be said to be
inspired by the thing it's replying to... maybe that's a bad example.

To follow mailing list standards there are replies to the Original
Poster or OP so maybe you could use rel="op". Replies via blog posts are
pretty much the same as an email reply, just in a different context.
Maybe it's not ideal but @rev can be really confusing sometimes as
demonstrated by the evidence.

Rob

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers


Hallvord R M Steen wrote:

"It's less typing" - Is that serious or are you joking?!



Isn't it? :)

  

Well sure, but I still don't know if that was a joke or whether it was a
serious point!



A bit of both. It's not an important point by any means, though I
think less verbosity is valuable :)

  


Having multiple URIs for different resources, when HTTP provides an 
alternative - is another type of  verbosity. I'd much rather have it in 
the markup, personally.



The language and even format of a resource is actually
often essential to that resource's identity. (The whole
content-negotiation idea is based on that statement being false. I
believe it's true.).

  


  

Language is a separate issue from content type. I would consider a
translated document as a separate resource which should be indicated in the
URL.



OK, we agree here.

  

For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.
  


  

If your system is designed to provide several different content types for
users to be able to read/write/update/delete a single resource from various
different User Agents - it's totally misleading to provide a separate URL
for each of them.
If I update the information in /report.pdf - does that update the
information in /report.html and /report.xml ? They're seperate resources
(indicated by seperate URLs) so from a 'usability' point of view, the
expected result should be to *only* update that the information in
/report.pdf.. but that's not actually the case here since the system will
update the information in the other two URLs aswell.



It's an interesting use case. It's also a simple UI issue that can be
solved on a UI level, if, say, my CMS shows that I'm about to update
"/report" or lists the files that will be affected. So this use case
doesn't need to be addressed at an architectural level where it will
have negative consequences for the usability of URLs.

  


That doesn't sound like it will end up very "uniform"!


This kind of behavior *breaks caching*, for obvious reasons.



Caches have to check whether resources are fresh according to caching
headers and/or settings anyway.

  


Don't reverse proxy caches automatically react to update the cache if a 
PUT or POST is performed on a given URI?



File types are all about convention. It's useful when sites follow the
convention, and it's a surprise in the rare event when they don't.
Since most of the time they do it's more useful than harmful.
  


  

What is the value of that 'convention'?



To me it's high, because it lets me E-mail/share URLs and be certain
of what variant the recipient sees, and it helps me decide whether or
not to open links I receive. ("Oh, that's a .ppt file - I don't have a
viewer for that so I won't bother").

  


You can be certain by telling them which UA is appropriate - if it's the 
same information but just in a different format, why does it matter that 
the content-type is different?



It only exists because of the present insufficiencies of HTML to provide
browsers with a way to leverage protocol level conneg.



Perhaps, but it has proven valuable in many other ways.

  


What are you measuring that value against?


My scepticism has nothing to do with whether it's easy to implement
(though I think you underestimate the required efforts - for example
the UA would need to verify that provided Accept: values are
correct/don't cause security problems etc.). My scepticism has nothing
to do with whether it is backwards compatible either. As a URL user I
just want to defend the usability of URLs against a theoretically more
pure but for practical purposes deeply flawed solution to a
non-problem.
  


  

It's interesting you mention security actually. Right now - as it stands -
your web browser is sending all of its requests  with an Accept header that
contains a catch-all "*/*". That is significantly less secure



This is incorrect. A malicious server can send you anything - no
matter what the Accept: header (and the extension) is. Browsers have
to deal with the fact that "anything" can come down the wire. (It
would certainly be *nice* if malicious servers started respecting
content negotiation and would stop sending you evil content if you
stopped sending "*/*" in the Accept: header but something tells me
things don't work that way).

  

- the fact
that you see .pdf at the end of the URL doesn't mean my server isn't about
to send you an executable. This is what I was referring to as "artificial
certainty".



If we implemented report
the server could respond with an executable too. This argument is
perfectly irrelevant to your case for HTTP-related attributes.
  


I agree, and it's in the rfc

Re: [whatwg] Absent rev?


Lachlan Hunt wrote:

Martin McEvoy wrote:
 From the "real world" found here: 
http://nfegen.wordpress.com/2008/03/28/micrordformats/


I read an interesting post recently, href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


An explicit one way relationship I might like to add to the hyperlink 
above may be rev="reply"


href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


It seems the "real world" example you point to doesn't actually use 
such a relationship, so I don't see how it qualifies as being real 
world example in this case.


In any case, if there was a real use case for such a relationship, 
then it rel="reply-to" would seem to be more appropriate.  It's 
meaning would then be roughly analogous to that of the In-Reply-To 
email header field. 

That was  a good example of how Murky @rel is compared to @rev

href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


would be 
 
is in reply to the referencing document surely?
(Although, I'm not convinced that there is a use case that really 
needs solving here, and speculating about the use of hypothetical 
relationships doesn't really provide any compelling evidence in 
support of the rev attribute.)




Thanks

--
Martin McEvoy

http://weborganics.co.uk/

Re: [whatwg] Absent rev?


Dan Brickley wrote:

Without rev, content creators (in every language) will need to go 
through this dance, hunting through dictionaries and debating 
subtleties, to make sure that they've identified a suitable pair of 
words such that { X word1 Y } is true if and only if { Y word1 X }. 
Which is why I see this in terms of division of labour. Cleaning it out 
of HTML5 makes work elsewhere...


Sorry that should've been,

{ X word1 Y } is true if and only if { Y word2 X }.

Dan

ps. (since i'm mailing again, sorry) ... in an RDF/XML context, we had 
this issue in FOAF: we added 'depicts' alongside 'depiction' because the 
old RDF/XML syntax didn't deal well with inverses

Re: [whatwg] Absent rev?


Smylers wrote:

Dan Brickley writes:


Smylers wrote:


Martin McEvoy writes:


!! rel-author doesn't mean the same as rev-made eg:

In which cases doesn't it?  If A is the author of B then B was made by
A, surely?

Then B contributed to the creation of A, yes. Perhaps not on their own.

But we need it in the other direction too: can we conclude from { A made  
B } that { B author A } ?


Not if B isn't textual. Authorship is about writing, but there are
many other avenues for human creativity (some of which result in
things with URLs, eg. software, images, sounds).


Firstly, the term author can be used for at least some of those things;
definitely software.


Yes, 'software' was a bad example. But Dublin Core certainly did abandon 
the early term 'author' in favour of 'creator' after a workshop looking 
at requirements around images, museum artifacts and so on.



Secondly, if you think made is more generic than author, then surely
linking to such URLs with rel=made is an improvement on using
rev=author?


I don't associate 'being more generic' as a positive or a negative 
thing. Sometimes we want specificity, sometimes not. There is value in a 
'see also' relationship type; there is value in a 'schoolHomepage' 
relationship type too. Neither need be better.


If I wanted to find written works, then 'author' is a more relevant 
property than 'made'. If my concern is to find all the things created by 
some party, then 'made' may be more useful. My point was just that they 
have a different meaning (although much overlap).



First is "a" versus "the". Nothing warrants reading "the" into
rel=author.


So presumably also nothing warrants reading "the" into rel=made?


Yup. If syntactic context (eg. via RDFa) associated the string 'made' 
with a specific definition rather than just the English word, then of 
course that definition could say anything it wanted - such as 'sole 
maker of ...' , 'primary maker of', etc.



The early Dublin Core specs had a "dc:author" property. This was
changed back in 1996 or so to be dc:creator,


I agree that creator would be a better term than author.  But I think
that's irrelevant to needing rev.


Without rev, content creators (in every language) will need to go 
through this dance, hunting through dictionaries and debating 
subtleties, to make sure that they've identified a suitable pair of 
words such that { X word1 Y } is true if and only if { Y word1 X }. 
Which is why I see this in terms of division of labour. Cleaning it out 
of HTML5 makes work elsewhere...


cheers,

Dan

--
http://danbri.org/



Smylers

Re: [whatwg] Absent rev?

2008-11-18 Thread Lachlan Hunt


Martin McEvoy wrote:
 From the "real world" found here: 
http://nfegen.wordpress.com/2008/03/28/micrordformats/


I read an interesting post recently, href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


An explicit one way relationship I might like to add to the hyperlink 
above may be rev="reply"


href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html"; 
title="Link to Mark Birbeck blog post">‘So how about using RDFa in 
Microformats?’


It seems the "real world" example you point to doesn't actually use such 
a relationship, so I don't see how it qualifies as being real world 
example in this case.


In any case, if there was a real use case for such a relationship, then 
it rel="reply-to" would seem to be more appropriate.  It's meaning would 
then be roughly analogous to that of the In-Reply-To email header field. 
 (Although, I'm not convinced that there is a use case that really 
needs solving here, and speculating about the use of hypothetical 
relationships doesn't really provide any compelling evidence in support 
of the rev attribute.)


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [whatwg] Video Element Events? - Use Case: Custom Progress Bar

2008-11-18 Thread Tab Atkins Jr.

On Tue, Nov 18, 2008 at 4:09 AM, timeless <[EMAIL PROTECTED]> wrote:

> On Tue, Nov 18, 2008 at 3:15 AM, Tab Atkins Jr. <[EMAIL PROTECTED]>
> wrote:
> > Keep in mind what we're dealing with here.
>
> dumb web authors. check.
>
> > This isn't some trivial Javascript timer firing off events at 60Hz.
>
> > This is a full 
> > element.  If a little "i++; if( i%60 == 0) {code}" is killing the CPU,
> then
> > that device isn't capable of playing a  either.
>
> if that little code causes the entire page to reflow because the web
> author is stupid, then it's a problem.
>
> if i'm really lucky my device might be able to use a special module to
> deal w/ video processing without killing my battery life.
>
> while i am praying that JIT will improve my life, it won't save my
> battery from stupid web authors and their pages.
>
> where possible we want to be able to optimize, video is something
> which can be handled by a specialized processor.
> javascript which causes the page to reflow because the author did
> something 'strange' which only effects my small device and didn't
> appear when he tested it on something else, otoh isn't something i can
> specialize. other than turning it off, and if i do that, people
> complain my product is broken.
>
> they also say my device sucks when the battery life doesn't match
> their expectations.
>
> sadly, customers are valuable.
>
> if the embedders (and antti clearly represents one, and I represent
> another) express clearly that they don't want something, it's probably
> a good idea to listen.
>
> while it's true that you could write code which checked a counter and
> only did work on the nth iteration, it's unlikely that you would. such
> counters are also likely to be calibrated for the wrong type of device
> meaning you get other problems - perhaps the progress bar doesn't
> update often enough on slower devices, and not because the event
> wasn't sent often enough but because it was filtered by the page.
>
> On Tue, Nov 18, 2008 at 1:19 AM, Robert O'Callahan <[EMAIL PROTECTED]>
> wrote:
> > That makes a lot more sense than limiting the timeupdate period.
> > Firing timeupdate on discontinuous changes and requiring apps
> > to also use a regular timer to get periodic updates sounds reasonable to
> me.
>
> this sounds good to me too.
>

After reading more feedback, I'm agreeing with you, but note that my
original point wasn't against what you were saying anyway.  ^_^  It was just
disputing that a counter-based js loop would kill performance.

Noted, though, that many people will, without thinking, just update on every
tick rather than figuring out what a significant interval to use is, and
that the potential differences in tick speed (4Hz to 66Hz right now, right?
somewhere around there?) mean that you *can't* just run a simple counter and
update every nth tick.  You'll still have to do some time comparisons.

~TJ

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

2008-11-18 Thread Thomas Broyer

On Tue, Nov 18, 2008 at 11:52 AM, Mike <[EMAIL PROTECTED]> wrote:
> Thomas Broyer wrote:
>>
>> On Mon, Nov 17, 2008 at 6:31 PM,  <[EMAIL PROTECTED]> wrote:
>>>
>>> - The HTML version of that URL could provide the web page representation
>>> *and* provide links to all the other content types available.
>>>
>>
>> How about other representations? (I know we're discussing HTML here,
>> and not HTTP, but what if a resource has no HTML representation? are
>> you proposing adding this capability to PDF, MSOffice, OpenDocument,
>> et al. too?)
>>
>
> That's an issue at the application level; RSS would work fine in that
> situation - any form of hypermedia will serve that purpose.

How would RSS work better than HTML (as of today; i.e. without your
proposed extension)?

>> Maybe you could explain how browsers do not conform to HTTP? (and no,
>> HTTP does not mandate user-agents to give the control of the Accept-*
>> headers to the user or the... server?!)
>>
>
> URI = Uniform Resource Identifier
>
> A given document available in html, pdf, xml - is one resource. The various
> content types are representations of that resource.

That's one way of looking at things, not *the* way (see below).

> Because HTML is presently insufficient in providing a mechanism for browsers
> to perform protocol level conneg.. it's been moved into the URI and each
> representation is provided as a separate resource. This clearly breaks the
> intended definition of a URI - this is why I don't consider browsers to
> conform to HTTP; since they force developers to misuse that part of the
> protocol.

If you want to precisely identify the PDF "version" of that document,
you need another resource (whose representations is a set with a
single value: PDF).
If your URI idenfies "this document", you cannot blame anyone but
yourself for not being able to identify "this document in PDF".

Anyway, we're going real far from this WG's scope, so I propose we
follow up in private, or, even better, you re-hash the debate on the
rest-discuss list or with Roy T. Fielding if you want.

> Having to use a JavaScript virtual machine to perform PUT and DELETE is yet
> another example of this.

Conforming to HTTP does not mean supporting all of the defined methods
(even at the server-side: a server is free to return a 501).

>> There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the
>> servers the ability to describe the available variants of a given
>> resource in a content-type independent way. You'd rather push browser
>> vendors to implement TCN/RSVA than HTML5 to add a content-type
>> dependent equivalent.
>>
>> See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5
>
> I don't really understand the point your making.. I would just like to see a
> way by which developers can link to *resources* with URIs and specify the
> representation if and when necessary for a given link.

So make another URI to identify that particular resource: "the same as
X but available only in format Y".

> There is no choice at the moment because HTML is insufficient.

I believe HTML is not in cause here (as any format with hyperlinking
feature would be "insufficient" too: as I said above: PDF, MSOffice,
OpenDocument, RSS, Atom, etc.)

>>> - I'll say it again: I'm encouraging you to help browsers become
>>> better HTTP clients; surely that is high on the agenda here.. right?!
>>>
>>
>> No, we're discussing HTML and some "Web APIs" here, not HTTP.
>>
>>
>>
>
> So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper
> Text are not closely linked?

No.
HTTP does not need HTML (WebDAV and CalDAV, for instance, do not need
HTML to work). and HTML does not need HTTP (aren't you sending HTML
mails yourself? and most documentation nowadays is in HTML format
stored on disk, without HTTP entering into play).
However, HTTP and HTML both make an heavy use of URI/URL.

>>> - separate versions are separate resources, not separate content types.
>>> That
>>> has nothing to do with conneg..
>>>
>>
>> s/version/variant/
>> Variants still need be produced by someone or something, and there
>> really might be discrepencies between them; that's why there's a
>> "quality" parameter in TCN/RSVA (and thus in Apache type-map files,
>> for instance)
>
> I'm not sure what you're getting at here. Multiple versions are multiple
> resources, they aren't seperate types so conneg is not appropriate. URIs
> handle this, the example I gave (which you left out) is proof of that.

Let me try again: your document is available in HTML and PDF (let's
keep it simple). Who makes the HTML? Who makes the PDF? How can you be
100%-sure that both variants are strictly "identical" (if ever they
can)?

Let's consider the famous "SVG tiger" image, that you would make
available in both SVG and PNG. Isn't the SVG qualitatively better than
the PNG? Aren't they the same resource "sketch of a tiger"?

How about an interactive animation you provide in both SVG+JS and
Flash. What if there's a b

Re: [whatwg] Absent rev?

Dan Brickley writes:

> Smylers wrote:
> 
> > Martin McEvoy writes:
> >
> > > !! rel-author doesn't mean the same as rev-made eg:
> >
> > In which cases doesn't it?  If A is the author of B then B was made by
> > A, surely?
> 
> Then B contributed to the creation of A, yes. Perhaps not on their own.
> 
> But we need it in the other direction too: can we conclude from { A made  
> B } that { B author A } ?
> 
> Not if B isn't textual. Authorship is about writing, but there are
> many other avenues for human creativity (some of which result in
> things with URLs, eg. software, images, sounds).

Firstly, the term author can be used for at least some of those things;
definitely software.

Secondly, if you think made is more generic than author, then surely
linking to such URLs with rel=made is an improvement on using
rev=author?

> First is "a" versus "the". Nothing warrants reading "the" into
> rel=author.

So presumably also nothing warrants reading "the" into rel=made?

> The early Dublin Core specs had a "dc:author" property. This was
> changed back in 1996 or so to be dc:creator,

I agree that creator would be a better term than author.  But I think
that's irrelevant to needing rev.

Smylers

Re: [whatwg] Absent rev?

Martin McEvoy writes:

> Smylers wrote:
> 
> > Martin McEvoy writes:
> >
> > > !! rel-author doesn't mean the same as rev-made eg:
> >
> > In which cases doesn't it?  If A is the author of B then B was made by
> > A, surely?
> 
> Its not explicit enough, there are times when there is a need to
> express  explicit relationships to things, a uniqueness that only you
> can relate  to, rev= is an explicit one way relationship from A to B

Sorry, I'm being unimaginative; please could you give an instance of
such a time?  Thanks.

> another example is ... An explicit one way relationship I might like
> to add to the hyperlink above may be rev="reply"

Or you could use rel with a word that means the opposite of reply, such
as rel=subject to denote the subject of your reply.

> > > "I have just finished this new   > > href="http://coolsite.co.uk/";> Cool website check it out""
> > >
> > > rev="author" is clearly better semantics in the  above case?
> >
> > Yes, if using rev.  Without rev it could be written as rel=made,
> > because made is the opposite of author.
> 
> ?... in the above example that would say  made
> the referring page? 

No, rel=author would say coolsite was the author of the current page,
whereas rel=made would say that the current page made coolsite; that's
the same as saying that coolsite was authored by the current page (which
is what rev=author would do).

> > > > The second most common value was rev="stylesheet", which is
> > > > meaningless and obviously meant to be rel="stylesheet".
> 
> That's just a matter of educating people

How would you propose we do that?  Clearly it's failed so far.

> not saying lets take rev away because you don't know how to use it?

If the number of people misusing rev was dwarfed by the much bigger of
correct uses of it, then obviously it wouldn't make sense to remove it.
But given that one of the most popular things to do with rev is to
misuse it, it clearly doesn't have much of a following for its intended
purpose.

> > > > Anything that could be done with rev="" can be done with rel=""
> > > > with an opposite keyword, so this omission should be easy to
> > > > handle.
> 
> as I have demonstrated above rev= a uniqueness, something that ONLY
>  can say about  .

I think I've demonstrated the opposite!

Smylers

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

Mike writes:

> Smylers wrote:
> 
> > [EMAIL PROTECTED] writes:
> >
> > > "... it'd be faster just to send the URL of the page which
> > > contains hypertext links to all the formats; at which point we no
> > > longer care whether those links specify the format in the URL or
> > > elsewhere."
> > >
> > > - The HTML version of that URL could provide the web page
> > > representation *and* provide links to all the other content types
> > > available.  
> >
> > Indeed it could.  In which case the original claimed advantage of the
> > recipient of the message being able to open a single URL in one of
> > several different sorts of user-agents is no longer relevant; the links
> > could specify the format in the URL and this'll work just fine.
> 
> You're completely missing my point here.

Sorry.

> I'm well aware that you can do conneg in the URL.

Good.

> HTTP provides a way to perform conneg at the protocol level;

Yes, I see that.

> no mechanism for this is currently provided by HTML.

And I see that as well.

What I'm missing is _why_ it would be advantageous to be able to do
this.

You originally suggested an advantage would be being able to have an
'ambiguous' URL, one which could provide a document in one of multiple
formats, and that passing such a URL to somebody else and enabling her
to download one of multiple formats of some content from that URL.

But we seemed to agree that in practice what would happen is the
recipient would load that URL in a browser to view the HTML format of
the document, and then, if she wants the PDF format she'd follow a link
in that HTML page.

So even though original URL _could_ have been opened in a PDF viewer,
that is never taken advantage of.

> Uniform *Resource* Identifier - different content types are different
> *representations*, not different resources.

That's certainly one possible interpretation, but I think treating
different formats of a document as different 'resources' is equally
plausible.

In practice web users don't often seem to use terms like 'resource' and
'respresentation'; they more commonly refer to 'documents', 'pages',
'formats'.  Two different formats of a document having two different
locations (and therefore implicitly being deemed to be two different
resources) isn't massively confusing for users, mainly cos they simply
don't think about the concept of what a resource is.

> Protocol level conneg was included in HTTP so that URI's would not
> have to be responsible..  unfortunately HTML didn't provide adequate
> mechanisms to make use of this - so everyone is used to conneg
> happening in the URI. That doesn't  make it 'the right way to do it'.
> Developers should be given the option.

What advantage would it be for a developer to do this?  As in why when
given the option would he choose to take it?

You've already pointed out that at least in the short term he'd have to
use both the URL and HTTP ways, so either way he'd always have to
provide the format selector in URLs.  Having done that, and it working
everywhere, he'd then have the option of either doing absolutely nothing
or of additionally doing some more work to do the same in HTTP.  Why
would he?

> > > HTTP provides conneg, why would you consciously deny developers
> > > the opportunity to use it in browsers?
> >
> > HTML 5 implicitly denies things merely by not providing them.  And it
> > provides things which are useful.  So the question actually needs to be
> > asked the other way round: what benefits are there in this being
> > supported?
> 
> The benefits? Oh I don't know.. a markup language that supports the  
> transfer protocol it runs on?!

That's circular: you're claiming the benefit of supporting this is so
that it is supported!  What's an actual advantage -- either a user
experience which is superior, or a situation in which developers would
choose to use it?

> This isn't a feature request - it's a bug. You're denying developers
> the ability to choose to use protocol level conneg.

True.  HTML 5 fails to provide developers the ability to do all sorts of
things.  That's only a problem for things which have real-world uses,
and I'm yet to grasp one for this proposed feature.

> > > "Not just browsers, as I pointed out.  Also many databases which
> > > have tables with URL fields would need extra fields adding."
> > >
> > > - I suggested the attribute should be optional, so it would make no
> > > difference; one would simply avoid using it if it was a big problem.
> >
> > If my database contains URLs of external websites, then it isn't under
> > my control as to whether this feature gets used.  If those sites start
> > using it, then my URLs are no longer sufficient to uniquely identify
> > what is downloaded, and I need to change my database schema (and
> > software that uses it) to remedy that.
> 
> They are completely sufficient, if you provided the link but with no  
> Accept attribute specified.. it would use the browser default (which is,  
> generally, html).

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers


Hallvord R M Steen wrote:

Sorry, both as an author and as a user I'd prefer this:
http://example.com/report";>html report
http://example.com/report.pdf";>pdf report
http://example.com/report.xhtml";>xml report

- Keep It Simple. For me as an author it's less typing, and for me as
a computer-literate end user it's clear whether a link is going to
make me wait for Acrobat loading or open directly - even if the link
is taken out of the HTML context.
  

"It's less typing" - Is that serious or are you joking?!



Isn't it? :)
  


Well sure, but I still don't know if that was a joke or whether it was a 
serious point!


  

I disagree; it's no more clear to end users. There is no reason the status
bar at the bottom couldn't say

http://example.com/report (PDF Document)

Trivial addition for browsers to take this information from the Accept
attribute.



Not quite "trivial", since browsers to do what you ask would need to
maintain a table of "pretty" names for all MIME types - including
translating that table to all languages the UI is translated to...
  


They could support the most common, the rest could be output 
"http://example.com/report (application/foo)". This problem is no better 
addressed using a URL.



On a more serious note: content negotiation is meant to automatically
choose a variant of a resource (format, language). However, in many
cases the variant is significant in a way that I as a user want
control over. The language and even format of a resource is actually
often essential to that resource's identity. (The whole
content-negotiation idea is based on that statement being false. I
believe it's true.).
  


Language is a separate issue from content type. I would consider a 
translated document as a separate resource which should be indicated in 
the URL. The same document provided in different formats is one resource 
and multiple representations. Representations are distinct from 
resources and therefore don't fit into the definition of Uniform 
Resource Locator.



I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure format
choice where the server and UA just agree on using the PNG or GIF
version for an  tag. For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.
  


If your system is designed to provide several different content types 
for users to be able to read/write/update/delete a single resource from 
various different User Agents - it's totally misleading to provide a 
separate URL for each of them. Because:


If I update the information in /report.pdf - does that update the 
information in /report.html and /report.xml ? They're seperate resources 
(indicated by seperate URLs) so from a 'usability' point of view, the 
expected result should be to *only* update that the information in 
/report.pdf.. but that's not actually the case here since the system 
will update the information in the other two URLs aswell.


This kind of behavior *breaks caching*, for obvious reasons.


As a URL user (web browsing human, HTML author, linker, bookmarker,
E-mail-with-links author) I often want to be sure about what variant
of a resource I link to. To be explicit about this across scenarios
requires explicit URLs with language and type information.

  

If you put .pdf at the end a URL the server wont necessarily
respond with a PDF content type, so any extra certainty you feel from that
is artificial.



File types are all about convention. It's useful when sites follow the
convention, and it's a surprise in the rare event when they don't.
Since most of the time they do it's more useful than harmful.

  


What is the value of that 'convention'?

It only exists because of the present insufficiencies of HTML to provide 
browsers with a way to leverage protocol level conneg.



Content negotiation is a lot nicer in theory than in practise..

  

Well it's not nice in practice because HTML is currently flawed



After thinking about it I've concluded that it's not nice in practice
because the basic premise of content negotiation is fundamentally
flawed, namely that what variant of a resource users get from a URL is
insignificant and what's best for them can be determined
automatically.

  


Automatically is the case for user agents that interpret specific 
content types; i.e. pdf readers would only Accept application/pdf documents.


Browsers are a specific type of user agent that are primarily used for 
reading hypermedia; but also, importantly, Accept many other different 
content types which they can pass to

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers

2008-11-18 Thread Hallvord R M Steen

>> Sorry, both as an author and as a user I'd prefer this:
>> http://example.com/report";>html report
>> http://example.com/report.pdf";>pdf report
>> http://example.com/report.xhtml";>xml report
>>
>> - Keep It Simple. For me as an author it's less typing, and for me as
>> a computer-literate end user it's clear whether a link is going to
>> make me wait for Acrobat loading or open directly - even if the link
>> is taken out of the HTML context.
>
> "It's less typing" - Is that serious or are you joking?!

Isn't it? :)

> I disagree; it's no more clear to end users. There is no reason the status
> bar at the bottom couldn't say
>
> http://example.com/report (PDF Document)
>
> Trivial addition for browsers to take this information from the Accept
> attribute.

Not quite "trivial", since browsers to do what you ask would need to
maintain a table of "pretty" names for all MIME types - including
translating that table to all languages the UI is translated to...

On a more serious note: content negotiation is meant to automatically
choose a variant of a resource (format, language). However, in many
cases the variant is significant in a way that I as a user want
control over. The language and even format of a resource is actually
often essential to that resource's identity. (The whole
content-negotiation idea is based on that statement being false. I
believe it's true.).

I've built two-three websites that use content/language negotiation
and I now consider it an architectural mistake to rely on negotiation
because the URLs no longer uniquely identify the variants I in many
scenarios need to identify. It's OK-ish to do it as a pure format
choice where the server and UA just agree on using the PNG or GIF
version for an  tag. For links *users* (and FWIW search engines,
validators and other agents) may interact with it's however a big
mistake to move away from one URL per variant of a resource. In light
of my content negotiation experiments and experience I'd say an Access
attribute in HTML would be harmful to the usability of URLs.

As a URL user (web browsing human, HTML author, linker, bookmarker,
E-mail-with-links author) I often want to be sure about what variant
of a resource I link to. To be explicit about this across scenarios
requires explicit URLs with language and type information.

> If you put .pdf at the end a URL the server wont necessarily
> respond with a PDF content type, so any extra certainty you feel from that
> is artificial.

File types are all about convention. It's useful when sites follow the
convention, and it's a surprise in the rare event when they don't.
Since most of the time they do it's more useful than harmful.

>> Content negotiation is a lot nicer in theory than in practise..
>>
>
> Well it's not nice in practice because HTML is currently flawed

After thinking about it I've concluded that it's not nice in practice
because the basic premise of content negotiation is fundamentally
flawed, namely that what variant of a resource users get from a URL is
insignificant and what's best for them can be determined
automatically.

> The apparent resistance to this confuses me; since the solution is not
> complicated to implement, completely backwards compatible, and ignorable.

My scepticism has nothing to do with whether it's easy to implement
(though I think you underestimate the required efforts - for example
the UA would need to verify that provided Accept: values are
correct/don't cause security problems etc.). My scepticism has nothing
to do with whether it is backwards compatible either. As a URL user I
just want to defend the usability of URLs against a theoretically more
pure but for practical purposes deeply flawed solution to a
non-problem.

-- 
Hallvord R. M. Steen

Re: [whatwg] Absent rev?

Hello...

Smylers wrote:

Martin McEvoy writes:

o be precise, the most commonly used value was rev="made", which is
equivalent to rel="author" and thus was not a convincing use case.

!! rel-author doesn't mean the same as rev-made eg:

In which cases doesn't it? If A is the author of B then B was made by
A, surely?

Its not explicit enough, there are times when there is a need to express
explicit relationships to things, a uniqueness that only you can relate
to, rev= is an explicit one way relationship from A to B

another example is (and I'm sure you have seen this kind of markup all
the time)

From the "real world" found here:
http://nfegen.wordpress.com/2008/03/28/micrordformats/

I read an interesting post recently, href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html";
title="Link to Mark Birbeck blog post">‘So how about using RDFa in
Microformats?’

An explicit one way relationship I might like to add to the hyperlink
above may be rev="reply"

href="http://internet-apps.blogspot.com/2008/03/so-how-about-using-rdfa-in-microformats.html";
title="Link to Mark Birbeck blog post">‘So how about using RDFa in
Microformats?’

the author would then be saying ...

is a reply to

"I have just finished this new href="http://coolsite.co.uk/";> Cool website check it out""

that would mean is the author of the referring
page which is nonsense.

Indeed, but nobody is suggesting that would be appropriate.

rev="author" is clearly better semantics in the above case?

Yes, if using rev. Without rev it could be written as rel=made, because
made is the opposite of author.

?... in the above example that would say made
the referring page?

The second most common value was rev="stylesheet", which is
meaningless and obviously meant to be rel="stylesheet".

That's just a matter of educating people not saying lets take rev away
because you don't know how to use it?

And that was the basis of the whatwg decision to drop rev? (I am not
criticizing just trying to understand it)

Data of what people have actually done, with the existence of current
browsers and standards, informs many decisions.

agreed..

surely all it needed was to define some rev values (the same as rel)
and people will start using rev correctly?

What semantics do you think authors who wrote rev=stylesheet were
meaning to convey? Presumably not that the webpage containing it is the
style-sheet for the CSS file that it linked to -- so it's definitely a
mistake by the author.

It was of course but how many authors make that mistake now?

If what the author meant to write was rel=stylesheet then HTML 5 is
surely an improvement, by dropping the confusing rev=stylesheet?

Or do you think something else is commonly meant by rev=stylesheet?

No what makes you think that?

We therefore determined that authors would benefit more from the
validator complaining about this attribute instead of supporting it.

Anything that could be done with rev="" can be done with rel="" with
an opposite keyword, so this omission should be easy to handle.

as I have demonstrated above rev= a uniqueness, something that ONLY
can say about .

There are some cases where that is just not possible.

Which?

see above.

Smylers

Thanks

--
Martin McEvoy

http://weborganics.co.uk/

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers


Smylers wrote:

[EMAIL PROTECTED] writes:

 

"Would the sender of that link necessarily know all the formats the URL
provides?  Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message and
send it without any surrounding text.

Whereas without any other information, people will generally open URLs
in a web browser.  So it'd be faster just to send the URL of the page
which contains hypertext links to all the formats; at which point we no
longer care whether those links specify the format in the URL or
elsewhere."

- The HTML version of that URL could provide the web page
representation *and* provide links to all the other content types
available.  


Indeed it could.  In which case the original claimed advantage of the
recipient of the message being able to open a single URL in one of
several different sorts of user-agents is no longer relevant; the links
could specify the format in the URL and this'll work just fine.

  


You're completely missing my point here. I'm well aware that you can do 
conneg in the URL. HTTP provides a way to perform conneg at the protocol 
level; no mechanism for this is currently provided by HTML.



"What is the point of doing it in HTTP if it's being done in HTML
anyway?"

- Nothing is 'done' in HTML, it's a markup language. It's being done
(at the moment) in the URI.



Sorry; that was what I meant.
  


Uniform *Resource* Identifier - different content types are different 
*representations*, not different resources. Protocol level conneg was 
included in HTTP so that URI's would not have to be responsible.. 
unfortunately HTML didn't provide adequate mechanisms to make use of 
this - so everyone is used to conneg happening in the URI. That doesn't 
make it 'the right way to do it'. Developers should be given the option.


 

HTTP provides conneg, why would you consciously deny developers the
opportunity to use it in browsers?



HTML 5 implicitly denies things merely by not providing them.  And it
provides things which are useful.  So the question actually needs to be
asked the other way round: what benefits are there in this being
supported?

  


The benefits? Oh I don't know.. a markup language that supports the 
transfer protocol it runs on?!


This isn't a feature request - it's a bug. You're denying developers the 
ability to choose to use protocol level conneg.



"Not just browsers, as I pointed out.  Also many databases which have
tables with URL fields would need extra fields adding."

- I suggested the attribute should be optional, so it would make no
difference; one would simply avoid using it if it was a big problem.



If my database contains URLs of external websites, then it isn't under
my control as to whether this feature gets used.  If those sites start
using it, then my URLs are no longer sufficient to uniquely identify
what is downloaded, and I need to change my database schema (and
software that uses it) to remedy that.

  


They are completely sufficient, if you provided the link but with no 
Accept attribute specified.. it would use the browser default (which is, 
generally, html). So that's a non-issue; It's backwards compatible.



"True.  But if the current way of doing it is good enough, there's no
incentive to change."

- Define 'enough'..! I don't know why/how you get the authority to
make that assumption!



I don't, of course!  But then, I never made that claim anyway; I said
_if_ it's good enough.

That is, in order to make this change let's first show that the current
way isn't good enough.
  


It's not good enough because it's merging representations (conneg) into 
resources (URIs). This isn't the way HTTP was intended to be used, 
that's just what people are used to. I'm not suggesting the current way 
of doing it should be abolished, I'm saying we should give people the 
choice. There is no choice at the moment (aside from using JavaScript). 
You're forcing me to repeat myself alot!


 

And before you say it; I'm not assuming any authority myself



Good; the editor has a policy of ignoring appeals to authority!
  


Like removing the ability to leverage protocol level conneg on the basis 
that "it works fine in the URI", for example?


 

"There's little point in making browsers implement extra functionality
and inventing new mark-up and evangelizing it, only to end up with the
same functionality we started with; there has to be more.  And the
greater the effort involved, the greater the benefit has to be to make
it worthwhile."

- I'll say it again: I'm encouraging you to help browsers become
better HTTP clients; surely that is high on the agenda here.. right?!



Why?  That's tantamount to an appeal to authority.  Fully supporting
HTTP is a means rather than an end.  Are there situations in which
supporting this particular part of HTTP provides additional benefit to
users?  Or are there many instances of authors tediously coding the

Re: [whatwg] Absent rev?


Smylers wrote:

Martin McEvoy writes:


o be precise, the most commonly used value was rev="made", which is
equivalent to rel="author" and thus was not a convincing use case. 

!! rel-author doesn't mean the same as rev-made eg:


In which cases doesn't it?  If A is the author of B then B was made by
A, surely?


Then B contributed to the creation of A, yes. Perhaps not on their own.

But we need it in the other direction too: can we conclude from { A made 
B } that { B author A } ?


Not if B isn't textual. Authorship is about writing, but there are many 
other avenues for human creativity (some of which result in things with 
URLs, eg. software, images, sounds).


So there are two complications here, and these are very real world 
issues, chewing up countless hours in projects like Dublin Core.


First is "a" versus "the". Nothing warrants reading "the" into 
rel=author. There might be other authors, listed or not listed in their 
own hyperlink. Or the page pointed to might be a collectively maintained 
page or group homepage etc. Or a mailto: for a mailing list.


Second is non-textual creations. The early Dublin Core specs had a 
"dc:author" property. This was changed back in 1996 or so to be 
dc:creator, since this better includes visual works, museum artifacts 
and so forth, ie. things that can be made, but which are not 
(postmodernism aside) conventionally considered texts. Authorship is a 
notion that doesn't make much sense in a non-textual context.


My point in previous mail about shifting work from HTML5 to elsewhere, 
is that this kind of distinction is subtle for many seemingly obvious 
pairs of relationship-type names, and that rev= is at least precise in 
its meaning.


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] Absent rev?

Martin McEvoy writes:

> > o be precise, the most commonly used value was rev="made", which is
> > equivalent to rel="author" and thus was not a convincing use case. 
>
> !! rel-author doesn't mean the same as rev-made eg:

In which cases doesn't it?  If A is the author of B then B was made by
A, surely?

> "I have just finished this new   href="http://coolsite.co.uk/";> Cool website check it out""
> 
> that would mean  is the author of the referring  
> page which is nonsense.

Indeed, but nobody is suggesting that would be appropriate.

> rev="author" is clearly better semantics in the  above case?

Yes, if using rev.  Without rev it could be written as rel=made, because
made is the opposite of author.

> > The second most common value was rev="stylesheet", which is
> > meaningless and obviously meant to be rel="stylesheet".
> 
> And that was the basis of the whatwg decision to drop rev? (I am not
> criticizing just trying to understand it)

Data of what people have actually done, with the existence of current
browsers and standards, informs many decisions.

> surely all it needed was to define some rev values (the same as rel)
> and people will start using rev correctly?

What semantics do you think authors who wrote rev=stylesheet were
meaning to convey?  Presumably not that the webpage containing it is the
style-sheet for the CSS file that it linked to -- so it's definitely a
mistake by the author.

If what the author meant to write was rel=stylesheet then HTML 5 is
surely an improvement, by dropping the confusing rev=stylesheet?

Or do you think something else is commonly meant by rev=stylesheet?

> > We therefore determined that authors would benefit more from the
> > validator complaining about this attribute instead of supporting it.
> >
> > Anything that could be done with rev="" can be done with rel="" with
> > an opposite keyword, so this omission should be easy to handle.
> 
> There are some cases where that is just not possible.

Which?

Smylers

Re: [whatwg] Absent rev?

Hello Ian

Ian Hickson wrote:

On Tue, 18 Nov 2008, Martin McEvoy wrote:

Just one small question

Why Has HTML5 dropped the rev=""[1] attribute?

[1] http://www.w3.org/TR/html5-diff/#absent-attributes

We did some studies and found that the attribute was almost never used,
and most of the time, when it was used, it was a typo where someone meant
to write rel="" but wrote rev="". To be precise, the most commonly used
value was rev="made", which is equivalent to rel="author" and thus was not
a convincing use case.

!! rel-author doesn't mean the same as rev-made eg:

"I have just finished this new href="http://coolsite.co.uk/";>Cool website check it out""

that would mean is the author of the referring
page which is nonsense. rev="author" is clearly better semantics in the
above case?
The second most common value was rev="stylesheet",
which is meaningless and obviously meant to be rel="stylesheet".
And that was the basis of the whatwg decision to drop rev? (I am not
criticizing just trying to understand it) surely all it needed was to
define some rev values (the same as rel) and people will start using rev
correctly?
We
therefore determined that authors would benefit more from the validator
complaining about this attribute instead of supporting it.

Anything that could be done with rev="" can be done with rel="" with an
opposite keyword, so this omission should be easy to handle.

There are some cases where that is just not possible.

Cheers,

Thanks

--
Martin McEvoy

http://weborganics.co.uk/

Re: [whatwg] [rest-discuss] HTML5 and RESTful HTTP in browsers


Thomas Broyer wrote:

On Mon, Nov 17, 2008 at 6:31 PM,  <[EMAIL PROTECTED]> wrote:
  

Would the sender of that link necessarily know all the formats the URL
provides?  Anyway, that's an unrealistic amount of typing -- typically
round here people just copy and paste a URL into an instant message
and send it without any surrounding text.

Whereas without any other information, people will generally open URLs
in a web browser.  So it'd be faster just to send the URL of the page
which contains hypertext links to all the formats; at which point we no
longer care whether those links specify the format in the URL or
elsewhere.
  

- The HTML version of that URL could provide the web page representation
*and* provide links to all the other content types available.



How about other representations? (I know we're discussing HTML here,
and not HTTP, but what if a resource has no HTML representation? are
you proposing adding this capability to PDF, MSOffice, OpenDocument,
et al. too?)
  
That's an issue at the application level; RSS would work fine in that 
situation - any form of hypermedia will serve that purpose.
  

What is the point of doing it in HTTP if it's being done in HTML anyway?
  

- Nothing is 'done' in HTML, it's a markup language. It's being done (at the
moment) in the URI. HTTP provides conneg, why would you consciously
deny developers the opportunity to use it in browsers? Unless HTML5
provides the markup, this isn't possible. This means Browsers don't have
the ability to fully support HTTP without having to use JavaScript rubbish;
there is a window of opportunity to change this with HTML5.



No. Browsers fully support HTTP in the sense that they send an Accept
header dependent of their *capabilities*.
If you want client-driven conneg, then use agent-driven/transparent
(RFCs 2295/2296), not server-driven conneg. This is explicitly noted
in RFC 2616 that server-driven negotiation has limits and can be
disadvantageous depending on your needs.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12

  


My argument is to provision both and let developers decide.


True.  But if the current way of doing it is good enough, there's no
incentive to change."
  

- Define 'enough'..! I don't know why/how you get the authority to
make that assumption! And before you say it; I'm not assuming any
authority myself - I'm trying to encourage you to help browsers conform
to the protocol they make use of.



Maybe you could explain how browsers do not conform to HTTP? (and no,
HTTP does not mandate user-agents to give the control of the Accept-*
headers to the user or the... server?!)
  


URI = Uniform Resource Identifier

A given document available in html, pdf, xml - is one resource. The 
various content types are representations of that resource.


Because HTML is presently insufficient in providing a mechanism for 
browsers to perform protocol level conneg.. it's been moved into the URI 
and each representation is provided as a separate resource. This clearly 
breaks the intended definition of a URI - this is why I don't consider 
browsers to conform to HTTP; since they force developers to misuse that 
part of the protocol.


Having to use a JavaScript virtual machine to perform PUT and DELETE is 
yet another example of this.



There's an extension to HTTP (TCN/RSVA, RFCs 2295/2296) that gives the
servers the ability to describe the available variants of a given
resource in a content-type independent way. You'd rather push browser
vendors to implement TCN/RSVA than HTML5 to add a content-type
dependent equivalent.

See also http://docs.google.com/View?docid=dggq7g95_10cd8zj5

  


I don't really understand the point your making.. I would just like to 
see a way by which developers can link to *resources* with URIs and 
specify the representation if and when necessary for a given link. There 
is no choice at the moment because HTML is insufficient. An optional 
Accept attribute would address this issue and still allow for the 
current methods that you feel (subjectively) are 'sufficient'.



- I'll say it again: I'm encouraging you to help browsers become
better HTTP clients; surely that is high on the agenda here.. right?!



No, we're discussing HTML and some "Web APIs" here, not HTTP.


  


So the Transfer Protocol (HTTP) and the Markup Language (HTML) for Hyper 
Text are not closely linked?


If you aren't discussing it that way; it might be worth considering, no?


Or what about if I wanted to mail somebody pointing out a discrepency
between two versions of the report, and wished to link to both of them.
That's tricky if they have the same URL.  Possibly I could do it like
you have with the wget command-line above, but that requires me knowing
which browsers my audience use and the precise syntax for them."
  

- separate versions are separate resources, not separate content types. That
has nothing to do with conneg..



s/version/variant/
Variants still need

Re: [whatwg] Absent rev?


Ian Hickson wrote:

On Tue, 18 Nov 2008, Martin McEvoy wrote:

Just one small question

Why Has HTML5 dropped the rev=""[1] attribute?

[1] http://www.w3.org/TR/html5-diff/#absent-attributes


We did some studies and found that the attribute was almost never used, 
and most of the time, when it was used, it was a typo where someone meant 
to write rel="" but wrote rev="". To be precise, the most commonly used 
value was rev="made", which is equivalent to rel="author" and thus was not 
a convincing use case. The second most common value was rev="stylesheet", 
which is meaningless and obviously meant to be rel="stylesheet". We 
therefore determined that authors would benefit more from the validator 
complaining about this attribute instead of supporting it.


(I don't dispute it's relative un-used-ness...)

Anything that could be done with rev="" can be done with rel="" with an 
opposite keyword, so this omission should be easy to handle.


This would seem to shift work from HTML5 to relationship vocabulary 
specs, whether RDFa-oriented or XFN-based: they'll have to name the 
relationship in both directions now.


eg.
john.html:
 See my dad's page for details
and

pa.html:
See my son's page for details

are ok in html5, but

pa.html: Reader,i'm his father

So long as there's a plausible inverse defined,

...isn't. I'm not arguing here that this is right or wrong or good or 
bad or pretty or ugly, just that the parties defining little 
relationship vocabularies such as 'parent', 'child', 
'father','mother','brother','ex-line-manager', and so on will (now 'rev' 
is going away) need to think carefully about naming each inverse 
relationship as well. As you point out, rev= wasn't heavily used anyway; 
however technologies like microformats and RDFa are relatively new to 
the Web, and things can take a while to get adopted (eg. XHR/'ajax').


cheers,

Dan

a personal ps.:
for some reason, rev= always made my head hurt slightly to even think 
about,  I guess because there are two senses of a reversed link: the 
reversed meaning of a link versus the idea of an incoming link / 
backlink, and the difference is simultaneously both obvious and subtle

Re: [whatwg] video tag: pixel aspect ratio

2008-11-18 Thread Sander van Zoest

On Mon, Nov 17, 2008 at 11:33 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote:

> On Tue, Nov 18, 2008 at 7:28 PM, Sander van Zoest <[EMAIL PROTECTED]>wrote:
>
>>
>> By the way, the "pixel-aspect-ratio" on video caps in the GStreamer
>>> framework has precisely the same meaning as this attribute, overriding
>>> it on a video sink also has an effect similar to what is suggested in
>>> the HTML5 spec. In other words, it's not so outlanding from a media
>>> framework's point of view.
>>
>>
>> In the capture world it makes a lot of sense. You are converting analog
>> content
>> into digital. It is my understanding that HTML5 is presentation
>> technology, not
>> a video capture, transcoding or editing framework.
>>
>
> Video capture is getting popular on the Web, so it would not be surprising
> to see HTML5 extend in that direction in the future.
>

Sure, let's cross that bridge when we get there. I certainly can see
usb-type cams and mics, but that is quite different then a full on video
capture framework.

-- Sander

Re: [whatwg] video tag: pixel aspect ratio

2008-11-18 Thread Philip Jägenstedt

On Mon, 2008-11-17 at 22:28 -0800, Sander van Zoest wrote:

> Depending on how you want to accomplish you can do that with an enum
> that defines how to handle the case:
> 
> 1) do nothing.
> 2) disproportionately adjust
> 3) stretch follow by letter-,pillar-,windowbox appropriately.
> 4) complete fill the screen and ignore overscan (ala pan & scan or
> zoom)

The spec says 3, but if stretch behaviour is wanted I guess one could
consider doing something like SVG:s preserveAspectRatio attribute[1]

> Oh, and if the video also needs cropping to get the correct
> aperture,
> couldn't this be done with CSS perhaps?
> 
> Wow. How would you know how much to crop for each video clip? Wouldn't
> specifying the enum above do the trick? 

I don't know, is aperture encoded in the media file itself or is it
implicit in certain types of video formats that aperture cropping (or
whatever the technical term is) should be applied? If you should always
crop e.g. 8 px on left and right then a CSS container with some overflow
tricks would certainly work. If on the other hand it's given in the
media file and it's likely to be incorrectly set then perhaps we do need
an override for it (although it's likely that such cropping is performed
by the video decoder and not a subsequent crop filter so it might not be
so trivial to fix in all media frameworks).

[1] http://www.w3.org/TR/SVG/coords.html#PreserveAspectRatioAttribute

-- 
Philip Jägenstedt
Opera Software

Re: [whatwg] Absent rev?

2008-11-18 Thread Ian Hickson

On Tue, 18 Nov 2008, Martin McEvoy wrote:
> 
> Just one small question
> 
> Why Has HTML5 dropped the rev=""[1] attribute?
> 
> [1] http://www.w3.org/TR/html5-diff/#absent-attributes

We did some studies and found that the attribute was almost never used, 
and most of the time, when it was used, it was a typo where someone meant 
to write rel="" but wrote rev="". To be precise, the most commonly used 
value was rev="made", which is equivalent to rel="author" and thus was not 
a convincing use case. The second most common value was rev="stylesheet", 
which is meaningless and obviously meant to be rel="stylesheet". We 
therefore determined that authors would benefit more from the validator 
complaining about this attribute instead of supporting it.

Anything that could be done with rev="" can be done with rel="" with an 
opposite keyword, so this omission should be easy to handle.

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

Re: [whatwg] Video Element Events? - Use Case: Custom Progress Bar

2008-11-18 Thread timeless

On Tue, Nov 18, 2008 at 3:15 AM, Tab Atkins Jr. <[EMAIL PROTECTED]> wrote:
> Keep in mind what we're dealing with here.

dumb web authors. check.

> This isn't some trivial Javascript timer firing off events at 60Hz.

> This is a full 
> element.  If a little "i++; if( i%60 == 0) {code}" is killing the CPU, then
> that device isn't capable of playing a  either.

if that little code causes the entire page to reflow because the web
author is stupid, then it's a problem.

if i'm really lucky my device might be able to use a special module to
deal w/ video processing without killing my battery life.

while i am praying that JIT will improve my life, it won't save my
battery from stupid web authors and their pages.

where possible we want to be able to optimize, video is something
which can be handled by a specialized processor.
javascript which causes the page to reflow because the author did
something 'strange' which only effects my small device and didn't
appear when he tested it on something else, otoh isn't something i can
specialize. other than turning it off, and if i do that, people
complain my product is broken.

they also say my device sucks when the battery life doesn't match
their expectations.

sadly, customers are valuable.

if the embedders (and antti clearly represents one, and I represent
another) express clearly that they don't want something, it's probably
a good idea to listen.

while it's true that you could write code which checked a counter and
only did work on the nth iteration, it's unlikely that you would. such
counters are also likely to be calibrated for the wrong type of device
meaning you get other problems - perhaps the progress bar doesn't
update often enough on slower devices, and not because the event
wasn't sent often enough but because it was filtered by the page.

On Tue, Nov 18, 2008 at 1:19 AM, Robert O'Callahan <[EMAIL PROTECTED]> wrote:
> That makes a lot more sense than limiting the timeupdate period.
> Firing timeupdate on discontinuous changes and requiring apps
> to also use a regular timer to get periodic updates sounds reasonable to me.

this sounds good to me too.

[whatwg] Absent rev?