subject:"\[whatwg\] RDFa"


On 18/1/09 21:04, Shelley Powers wrote:

Dan Brickley wrote:

On 18/1/09 20:07, Henri Sivonen wrote:

On Jan 18, 2009, at 20:48, Dan Brickley wrote:


On 18/1/09 19:34, Henri Sivonen wrote:

On Jan 18, 2009, at 01:32, Shelley Powers wrote:


Are you then saying that this will be a showstopper, and there will
never be either a workaround or compromise?



Are the RDFa TF open to compromises that involve changing the XHTML
side
of RDFa not to use attribute whose qualified name has a colon in
them to
achieve DOM Consistency by changing RDFa instead of changing parsing?


I don't believe the RDFa TF are in a position to singlehandedly
rescind a W3C Recommendation, ie.
http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/.

What they presumably could do is propose new work items within W3C,
which I'd guess would be more likely to be accepted if it had the
active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who
might have something more to add.

Do you have an alternative design in mind, for expressing the
namespace mappings?


The simplest thing is not to have mappings but to put the corresponding
absolute URI wherever RDFa uses a CURIE.


So this would be a kind of "interoperability profile" of RDFa, where
certain features approved of by REC-rdfa-syntax-20081014 wouldn't be
used in some hypothetical HTML5 RDFa.

If people can control their urge to use namespace abbreviations, and
stick to URIs directly, would this make your DOM-oriented concerns go
away?


Took five minutes to make this change in my template. Ran through
validator.nu. Results:

Doesn't like the content-type. Didn't like profile on head. Having to
remove the profile attribute in my head element limits usability, but
I'm not going to throw myself on the sword for this one.

Doesn't like property, doesn't like about. These are the RDFa attributes
I'm using. The RDF extractor doesn't care that I used the URIs directly.


This sounds encouraging. Thanks for taking the time to try the 
experiment,  Shelley. But ... to be clear, are you putting full URIs in 
the @property attribute too? In 
http://www.w3.org/TR/rdfa-syntax/#s_curieprocessing it says '@property, 
@datatype and @typeof support only CURIE values.'


(Can you post an example?)

Reading ...
"""Many of the attributes that hold URIs are also able to carry 'compact 
URIs' or CURIEs. A CURIE is a convenient way to represent a long URI, by 
replacing a leading section of the URI with a substitution token. It's 
possible for authors to define a number of substitution tokens as they 
see fit; the full URI is obtained by locating the mapping defined by a 
token from a list of in-scope tokens, and then simply concatenating the 
second part of the CURIE onto the mapped value."""


... I guess the fact that @property is supposed to be CURIE-only isn't a 
problem with parsers since this can be understood as a CURIE with no (or 
empty) substitution token.


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 18, 2009, at 21:45, Dan Brickley wrote:

If people can control their urge to use namespace abbreviations, and  
stick to URIs directly, would this make your DOM-oriented concerns  
go away?


Yes, it would make my DOM Consistency concern go away if the urge were  
thus controlled for both HTML and XHTML.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On 18/1/09 20:07, Henri Sivonen wrote:

On Jan 18, 2009, at 20:48, Dan Brickley wrote:


On 18/1/09 19:34, Henri Sivonen wrote:

On Jan 18, 2009, at 01:32, Shelley Powers wrote:


Are you then saying that this will be a showstopper, and there will
never be either a workaround or compromise?



Are the RDFa TF open to compromises that involve changing the XHTML side
of RDFa not to use attribute whose qualified name has a colon in them to
achieve DOM Consistency by changing RDFa instead of changing parsing?


I don't believe the RDFa TF are in a position to singlehandedly
rescind a W3C Recommendation, ie.
http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/.

What they presumably could do is propose new work items within W3C,
which I'd guess would be more likely to be accepted if it had the
active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who
might have something more to add.

Do you have an alternative design in mind, for expressing the
namespace mappings?


The simplest thing is not to have mappings but to put the corresponding
absolute URI wherever RDFa uses a CURIE.


So this would be a kind of "interoperability profile" of RDFa, where 
certain features approved of by REC-rdfa-syntax-20081014 wouldn't be 
used in some hypothetical HTML5 RDFa.


If people can control their urge to use namespace abbreviations, and 
stick to URIs directly, would this make your DOM-oriented concerns go away?


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 18, 2009, at 20:48, Dan Brickley wrote:


On 18/1/09 19:34, Henri Sivonen wrote:

On Jan 18, 2009, at 01:32, Shelley Powers wrote:


Are you then saying that this will be a showstopper, and there will
never be either a workaround or compromise?



Are the RDFa TF open to compromises that involve changing the XHTML  
side
of RDFa not to use attribute whose qualified name has a colon in  
them to

achieve DOM Consistency by changing RDFa instead of changing parsing?


I don't believe the RDFa TF are in a position to singlehandedly  
rescind a W3C Recommendation, ie. http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/ 
.


What they presumably could do is propose new work items within W3C,  
which I'd guess would be more likely to be accepted if it had the  
active enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who  
might have something more to add.


Do you have an alternative design in mind, for expressing the  
namespace mappings?



The simplest thing is not to have mappings but to put the  
corresponding absolute URI wherever RDFa uses a CURIE.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Sam Ruby

On Sun, Jan 18, 2009 at 1:34 PM, Henri Sivonen  wrote:
> On Jan 18, 2009, at 01:32, Shelley Powers wrote:
>
>> Are you then saying that this will be a showstopper, and there will never
>> be either a workaround or compromise?
>
> Are the RDFa TF open to compromises that involve changing the XHTML side of
> RDFa not to use attribute whose qualified name has a colon in them to
> achieve DOM Consistency by changing RDFa instead of changing parsing?

Just so that we have all of the data available to make an informed
decision, do we have examples of how it would "break the web" if
attributes which started with the characters "xmlns:" (and *only*
those attribute) were placed into the DOM exactly as they would be
when those bytes are processed as XHTML?

Notes: I am *not* suggesting anything just yet, other than the
gathering of this data.  I also recognize that this would require a
parsing change by browser vendors, which also is a cost that needs to
be factored in.  But right now, I am interested in how it would affect
the web if this were done.

> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On 18/1/09 19:34, Henri Sivonen wrote:

On Jan 18, 2009, at 01:32, Shelley Powers wrote:


Are you then saying that this will be a showstopper, and there will
never be either a workaround or compromise?



Are the RDFa TF open to compromises that involve changing the XHTML side
of RDFa not to use attribute whose qualified name has a colon in them to
achieve DOM Consistency by changing RDFa instead of changing parsing?


I don't believe the RDFa TF are in a position to singlehandedly rescind 
a W3C Recommendation, ie. 
http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/.


What they presumably could do is propose new work items within W3C, 
which I'd guess would be more likely to be accepted if it had the active 
enthusiasm of the core HTML5 team. Am cc:'ing TimBL here who might have 
something more to add.


Do you have an alternative design in mind, for expressing the namespace 
mappings?


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 18, 2009, at 01:32, Shelley Powers wrote:

Are you then saying that this will be a showstopper, and there will  
never be either a workaround or compromise?



Are the RDFa TF open to compromises that involve changing the XHTML  
side of RDFa not to use attribute whose qualified name has a colon in  
them to achieve DOM Consistency by changing RDFa instead of changing  
parsing?


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Anne van Kesteren

On Sun, 18 Jan 2009 17:43:12 +0100, Shelley Powers  
 wrote:

Anne van Kesteren wrote:
On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers  
 wrote:
And regardless of the fact that I jumped to conclusions about WhatWG  
membership, I do not believe I was inaccurate with the earlier part of  
this email. Sam started a new thread in the discussion about the  
issues of namespace and how, perhaps we could find a way to work the  
issues through with RDFa. My god, I use RDFa in my pages, and they  
load fine with any browser, including IE. I have to believe its  
incorporation into HTML5 is not the daunting effort that others make  
it seem to be.'


You ask us to take you seriously and consider your feedback, it would  
be nice if you took what e.g. Henri wrote seriously as well.  
Integrating a new feature in HTML is not a simple task, even if the new  
feature loads and renders fine in Internet Explorer.



Take you guys seriously...OK, yeah.


Well, if you don't there is not much point debating with each other, is  
there?



I don't doubt that the work will be challenging, or problematical. I'm  
not denying Henri's claim. And I didn't claim to be the one who would  
necessarily come up with the solutions, either, but that I would help in  
those instances that I could.


About forty minutes ago you claimed that you had to believe incorperating  
RDFa is not the daunting effort that others make it out to be. (See the  
quoted portion above.)



What I did express in the later emails, is what others have expressed  
who have asked about RDFa in HTML5: are we wasting our time even trying?  
That it seems like a decision has already been made, and we're spinning  
our wheels even attempting to find solutions. There's a difference  
between not being willing to negotiate, compromise, work the problem,  
and just spitting into the wind for no good.


The way features traditionally have been going into HTML5 has been through  
use cases, research, etc. Ian and others are proposing to do the exact  
same thing for RDFa. This means it will take a while before there is a  
definitive answer and it will also require work to be done by interested  
parties. In comment threads on your blog various RDFa proponents seemed to  
be willing to help out with this.


Having that data available will allow people to more objectively judge  
whether RDFa should be integrated in HTML5, and if so, how. Without having  
that data available RDFa proponents will simply say yes and detractors  
will simply say no and nobody is any wiser as to who is right.



No, Ian's listing of tasks pretty much precluded any input into the  
decision making process other than his own. I never see "we" when Ian  
writes, I only see "I".


If he makes a decision and a majority of people disagree with him based on  
the data provided I'm sure he'll change his mind or improve his own  
research trying to convince the rest of the WG. This has happened before.


Also, input into the process can certainly be (and has been) given, in the  
form of research, use cases, etc.



--
Anne van Kesteren

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Shelley Powers


Anne van Kesteren wrote:
On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers 
 wrote:
And regardless of the fact that I jumped to conclusions about WhatWG 
membership, I do not believe I was inaccurate with the earlier part 
of this email. Sam started a new thread in the discussion about the 
issues of namespace and how, perhaps we could find a way to work the 
issues through with RDFa. My god, I use RDFa in my pages, and they 
load fine with any browser, including IE. I have to believe its 
incorporation into HTML5 is not the daunting effort that others make 
it seem to be.'


You ask us to take you seriously and consider your feedback, it would 
be nice if you took what e.g. Henri wrote seriously as well. 
Integrating a new feature in HTML is not a simple task, even if the 
new feature loads and renders fine in Internet Explorer.



Take you guys seriously...OK, yeah.

I don't doubt that the work will be challenging, or problematical. I'm 
not denying Henri's claim. And I didn't claim to be the one who would 
necessarily come up with the solutions, either, but that I would help in 
those instances that I could.


What I did express in the later emails, is what others have expressed 
who have asked about RDFa in HTML5: are we wasting our time even trying? 
That it seems like a decision has already been made, and we're spinning 
our wheels even attempting to find solutions. There's a difference 
between not being willing to negotiate, compromise, work the problem, 
and just spitting into the wind for no good.



However, the debate ended as soon as Ian re-asserted his authority.


Ian just gave an indication of when he's going to work on this again. 
That doesn't mean that research into e.g. DOM consistency can't happen 
meanwhile. It also doesn't mean that debate needs to stop.



No, Ian's listing of tasks pretty much precluded any input into the 
decision making process other than his own. I never see "we" when Ian 
writes, I only see "I".


Regardless, perhaps Dan or Ben have better arguments than I do to input 
into the debate. I'm not helping.


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Anne van Kesteren

On Sun, 18 Jan 2009 17:15:34 +0100, Shelley Powers  
 wrote:
And regardless of the fact that I jumped to conclusions about WhatWG  
membership, I do not believe I was inaccurate with the earlier part of  
this email. Sam started a new thread in the discussion about the issues  
of namespace and how, perhaps we could find a way to work the issues  
through with RDFa. My god, I use RDFa in my pages, and they load fine  
with any browser, including IE. I have to believe its incorporation into  
HTML5 is not the daunting effort that others make it seem to be.'


You ask us to take you seriously and consider your feedback, it would be  
nice if you took what e.g. Henri wrote seriously as well. Integrating a  
new feature in HTML is not a simple task, even if the new feature loads  
and renders fine in Internet Explorer.




However, the debate ended as soon as Ian re-asserted his authority.


Ian just gave an indication of when he's going to work on this again. That  
doesn't mean that research into e.g. DOM consistency can't happen  
meanwhile. It also doesn't mean that debate needs to stop.



--
Anne van Kesteren

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Shelley Powers


Anne van Kesteren wrote:
On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers 
 wrote:
My apologies for not responding sooner to this thread. You see, one 
of the WhatWG working group members thought it would be fun to add a 
comment to my Stop Justifying RDF and RDFa web post, which caused the 
page to break. I am using XHTML at my site, because I want to 
incorporate inline SVG, in addition to RDFa. An unfortunate 
consequence of XHTML is its less than forgiving nature regarding 
playful pranks such as this.


I'm assuming the WhatWG member thought the act was clever. It was, 
indeed. Three people emailed me to let me know the post was breaking 
while loading the page in a browser, and I made sure to note that 
such breakage was courtesy of a WhatWG member, who decided that 
perhaps I should just shut up, here and at my site, about the 
Important Work people(?) here are doing.


Of course, the person only highlighted why it is so important that 
something such as RDFa, and SVG, and MathML, get a home in HTML5. 
XHTML is hard to support when you're allowing comments and external 
input. Typically my filters will catch the accidental input of crappy 
markup, but not the intentional. Not yet. I'm not an exerpt at 
markup, but I know more than the average person. And the average 
person most likely doesn't have my commitment, either.


http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who 
by the way seems to be on your side in this debate) simply forgot to 
escape  and then WordPress somehow messed up in an 
attempt to fix it. I don't think anyone tries to make you "shut up".



(And if we, the evil WHATWG cabal, wanted to break your site, we 
would've asked Philip` ;-))



You're not seeing all of the markup that caused problems, Anne. The 
intention was to crash the post. However, I shouldn't have assumed that 
the person who inserted the markup that caused the problems is a WhatWG 
member. My apologies.


Regardless of intent, it does demonstrate, again, why it is important 
for RDFa, SVG, and MathML find a home in HTML5. XHTML is a very 
difficult markup to support when you're allowing outside input. The 
tools do not do a good job of supporting XHTML, and hence the average 
person finds such failures to be intimidating, and will immediately 
return to HTML. Heck, I find the yellow screen of death to be unnerving 
myself. It's only my interest in inline SVG and RDFa, and basically 
distributed extensibility, that keeps me trying.


And regardless of the fact that I jumped to conclusions about WhatWG 
membership, I do not believe I was inaccurate with the earlier part of 
this email. Sam started a new thread in the discussion about the issues 
of namespace and how, perhaps we could find a way to work the issues 
through with RDFa. My god, I use RDFa in my pages, and they load fine 
with any browser, including IE. I have to believe its incorporation into 
HTML5 is not the daunting effort that others make it seem to be.'


However, the debate ended as soon as Ian re-asserted his authority.

Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Anne van Kesteren

On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers  
 wrote:
My apologies for not responding sooner to this thread. You see, one of  
the WhatWG working group members thought it would be fun to add a  
comment to my Stop Justifying RDF and RDFa web post, which caused the  
page to break. I am using XHTML at my site, because I want to  
incorporate inline SVG, in addition to RDFa. An unfortunate consequence  
of XHTML is its less than forgiving nature regarding playful pranks such  
as this.


I'm assuming the WhatWG member thought the act was clever. It was,  
indeed. Three people emailed me to let me know the post was breaking  
while loading the page in a browser, and I made sure to note that such  
breakage was courtesy of a WhatWG member, who decided that perhaps I  
should just shut up, here and at my site, about the Important Work  
people(?) here are doing.


Of course, the person only highlighted why it is so important that  
something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML  
is hard to support when you're allowing comments and external input.  
Typically my filters will catch the accidental input of crappy markup,  
but not the intentional. Not yet. I'm not an exerpt at markup, but I  
know more than the average person. And the average person most likely  
doesn't have my commitment, either.


http://annevankesteren.nl/2009/01/xml-sunday shows the commentor (who by  
the way seems to be on your side in this debate) simply forgot to escape  
 and then WordPress somehow messed up in an attempt to fix  
it. I don't think anyone tries to make you "shut up".



(And if we, the evil WHATWG cabal, wanted to break your site, we would've  
asked Philip` ;-))



--
Anne van Kesteren

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Shelley Powers


Ian Hickson wrote:

On Sat, 17 Jan 2009, Sam Ruby wrote:
  
But back to expectations.  I've seen references elsewhere to Ian being 
booked through the end of this quarter.  I may have misheard, but in any 
case, my point is the same: if this is awaiting something from Ian, it 
will be prioritized and dealt with accordingly.



For what it's worth, my current plan running up to last call in October 
includes an item in April for me to go through all the use cases that have 
by that point been put forward in the data markup space, and to work out 
for each use case and on the aggregate:


1. Whether there is compelling evidence that users want that use case 
   addressed (e.g. whether there are successful companies addressing that 
   use case using proprietary solutions or ad-hoc extensions to HTML, or
   whether there are usability studies or some independent market research 
   showing demand from users, or whether it can be demonstrated that users 
   are avoiding the Web because it doesn't address this problem).
  


Again, you've become gatekeeper Ian. You are the one making the decision 
as to worth. You are the only one, as far as I can see, that is making 
decisions about what is, or is not included in the next version of HTML.


You use "I" so frequently. Reading through your emails, one can't help 
wondering if you're the lead singer and everyone else here is nothing 
more than a faint echo.


2. Whether the use case is being addressed well enough already (e.g. if 
   there are companies addressing this use case adequately, or whether the 
   current solutions really are just hacks with numerous problems).


3. What the requirements are for each use case.

4. What solutions are available to address these use cases.

5. For each solution, whether it addresses the requirements.

6. Whether the relevant implementors are interested in implementing 
   solutions for these use cases (e.g. whether authoring tools are willing 
   to expose the feature, whether validator writers want to check for the 
   correctness, whether browser vendors are willing to expose the relevant 
   UI, whether search engine companies are willing to use the data, or 
   whatever else might be appropriate).


The more use cases there are, the better informed the results will be.

  


The point isn't to provide use cases. The point is to highlight a 
serious problem with this working group--there is a mindset of what the 
future of HTML will look like, and the holders of the mindset brook no 
challenge, tolerate no disagreement, and continually move to quash any 
possibility of asserting perhaps even the faintest difference of opinion.


My apologies for not responding sooner to this thread. You see, one of 
the WhatWG working group members thought it would be fun to add a 
comment to my Stop Justifying RDF and RDFa web post, which caused the 
page to break. I am using XHTML at my site, because I want to 
incorporate inline SVG, in addition to RDFa. An unfortunate consequence 
of XHTML is its less than forgiving nature regarding playful pranks such 
as this.


I'm assuming the WhatWG member thought the act was clever. It was, 
indeed. Three people emailed me to let me know the post was breaking 
while loading the page in a browser, and I made sure to note that such 
breakage was courtesy of a WhatWG member, who decided that perhaps I 
should just shut up, here and at my site, about the Important Work 
people(?) here are doing.


Of course, the person only highlighted why it is so important that 
something such as RDFa, and SVG, and MathML, get a home in HTML5. XHTML 
is hard to support when you're allowing comments and external input. 
Typically my filters will catch the accidental input of crappy markup, 
but not the intentional. Not yet. I'm not an exerpt at markup, but I 
know more than the average person. And the average person most likely 
doesn't have my commitment, either.


Someone earlier said that HTML5 is for web application users, only, and 
that the rest of us interested in things like RDFa should just use 
XHTML. In other words, make it good for Google and to hell with the rest 
of us. This, this is the guiding attitude behind the future of the web?


Regardless, I got the point in the comment. That, combined with this 
email from Ian, tells us that it doesn't matter how our arguments run, 
the logic of our debate, the rightness of our cause--he is the final 
arbiter, and he does not want RDFa. I am not paid by Google, or Mozilla, 
or IBM to continue throwing away my time, arguing for naught.


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-18 Thread Ian Hickson

On Sun, 18 Jan 2009, Dan Brickley wrote:
> On 18/1/09 00:24, Henri Sivonen wrote:
> > 
> > No. However, most of the time, when people publish HTML, they do it to 
> > elicit browser behavior when a user loads the HTML document in a 
> > browser.
> 
> Most users of the Web barely know what a browser is, let alone HTML. 
> They're just putting information online; perhaps into a closed site (eg. 
> facebook), perhaps into a public-facing site (eg. a blog), or perhaps 
> into 1:1, group or IM messaging (eg. webmail). [...]
>
> The reason for my pedantry here is not to be argumentative, but just to
> suggest that this (otherwise very natural) thinking leads us to forget about
> the other major consumers of HTML - search engine. [...]
> 
> Aren't search engines equally important consumers of HTML? Perhaps 
> they're more simple-minded in their behaviour than a full UI browser. 
> But from the user side, there's only slightly more value in being 
> readable without being findable than vice-versa...

Speaking at least from Google's perspective, we've found that the closer 
we get to emulating a browser, the better our results get. I would say 
that even if they don't realise it, authors are by and large acting pretty 
much exactly as Henri describes, and they expect their non-browser tools, 
such as their search engines, to just Do The Right Thing.

This is reflected in the great difficulty we (the standards community) 
have had in convincing authors to use CSS. The mere idea that authors 
should mark up their text as headings and then make their headings big is 
often faced by the simple reply "But I just want my text to be big".

I'm not trying to draw any value judgements here, though. Personally I'd 
love it if authors could just mark up their content purely semantically 
and have the browsers Do The Right Thing the way that search engines have 
to now based on the few semantics (and ample presentational hints) that 
authors use. But in my experience most authors don't think that way, and 
aren't interested in thinking that way.

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

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On 18/1/09 00:24, Henri Sivonen wrote:


No. However, most of the time, when people publish HTML, they do it to
elicit browser behavior when a user loads the HTML document in a browser.


Most users of the Web barely know what a browser is, let alone HTML. 
They're just putting information online; perhaps into a closed site (eg. 
facebook), perhaps into a public-facing site (eg. a blog), or perhaps 
into 1:1, group or IM messaging (eg. webmail). HTML figures in all these 
scenarios. Browsers or HTML rendering code too, of course. But I don't 
think we can jump from that to claims about user intent, and more than 
their use of the Internet signifies an intent to have their information 
chopped up into packets and transmitted according to the rules of TCP/IP.


The reason for my pedantry here is not to be argumentative, but just to 
suggest that this (otherwise very natural) thinking leads us to forget 
about the other major consumers of HTML - search engines. Having their 
stuff found and linked by other is often a big part of the motivation 
for putting stuff online. HTML parsing is involved, impact on the needs 
and interests of mainstream users is involved; but it's not clear 
whether all/any/many users 'do it to elicit search engine behaviour when 
indexing the HTML document'.


Aren't search engines equally important consumers of HTML? Perhaps 
they're more simple-minded in their behaviour than a full UI browser. 
But from the user side, there's only slightly more value in being 
readable without being findable than vice-versa...


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On 17/1/09 23:30, L. David Baron wrote:

On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote:

The story of RDF is very different. Of the top four engines, only Gecko
has RDF functionality. It was implemented at a time when RDF was a young
W3C REC and stuff that were W3C RECs were implemented less critically
than nowadays.

Actually, the implementation was well underway *before* RDF was a
W3C REC, done by a team led by one of the designers of RDF. In
other words, it was in Gecko because there were RDF advocates at
Netscape (although advocating, I think, a somewhat different RDF
than the current RDF recommendations).

Yes, Netscape had this stuff when it was still called MCF. W3C's RDF
took ideas from several input activities, including MCF, Microsoft
XML-Data, PICS, and requirements from the Dublin Core community. But it
looks more like MCF than the others.

MCF was originally proposed by R.V.Guha at Apple; it followed him from
Apple to Netscape in 1997, and when the Mozilla sources were later
thrown over the wall, there was a lot of MCF in there.

MCF White Paper, 1996 http://www.guha.com/mcf/wp.html
spec, http://www.guha.com/mcf/mcf_spec.html

While this was at Apple, there was a product/viewer called HotSauce /
Project X, and some early grassroots adoption of MCF as a text format
for publishing website summaries.

http://web.archive.org/web/19961224042753/http://hotsauce.apple.com/
http://downlode.org/Etext/MCF/macworld_online.html

It was at this stage that dialog started with the Library scene and
Dublin Core folk, about how it related to their notion of catalogue
records, and to the evolving PICS labelling system, format and protocol
being built at W3C.

eg.
http://www.ssrc.hku.hk/tb-issues/TidBITS-355.html#lnk3
http://web.archive.org/web/19980215092626/http://www.ariadne.ac.uk/issue7/mcf/
The MCF/RSS relationship is a whole other story, eg. see
http://www.scripting.com/midas/mcf.html
http://www.scripting.com/frontier/siteMap.mcf
http://web.archive.org/web/19990222114619/http://www.xspace.net/hotsauce/sites.html

Then the thing moved to Netscape. Tim Bray helped Guha XMLize the spec,
which was submitted to W3C in 1997, where it joined the existing efforts
to extend PICS to include text labels and more structure -
http://www.w3.org/TR/NOTE-pics-ng-metadata

http://www.daml.org/committee/minutes/2000-12-07-RDF-design-rationale.ppt
http://searchenginewatch.com/2165291

So the June 97 spec was
http://www.w3.org/TR/NOTE-MCF-XML/
.. you can see from the figures that the technology was very RDF-shaped,
http://www.w3.org/TR/NOTE-MCF-XML/#sec2. Also a tutorial at
http://www.w3.org/TR/NOTE-MCF-XML/MCF-tutorial.html

Netscape press release accompanying June 13 1997 submission -
http://web.archive.org/web/20010308150737/http://cgi.netscape.com/newsref/pr/newsrelease432.html

Less than 4 months later, this came out as a W3C Working Draft called
"RDF": http://www.w3.org/TR/WD-rdf-syntax-971002/
... in a shape that didn't really change much subsequently. RDF wasn't
the same design exactly as MCF but the ancestry is clear enough.

And getting back to the original point, yeah Mozilla had MCF sitemaps
code in there.

Revisiting
http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/story/9-8-97/312711&EDATE=

http://www.irt.org/articles/js086/ and the like, it's clear that RDF was
very much a child of the 1st browser wars.

In retrospect the direction it took within Mozilla didn't do anyone much
good. The earliest MCF apps were about public data on the public Web,
feeds, sitemaps and so on. But eventually the ambition to be a complete
information hub led to MCF/RDF being used for pretty much everything
*inside* Mozilla. And I don't think that turned out very well.
http://www.mozilla.org/rdf/doc/api.html etc. The RDF vocabularies it
used were poorly or never documented (I have some guilt there) and when
Netscape went away, the incentive to connect to public data on the Web
seemed to drop (no more tie-ins with the 'what's related' annotation
server, 'dmoz' etc.). RDF drifted from being a Web data format to be
consumed *by* the browser, into an engineering tool to be used in the
construction *of* the browser, ie. as a datasource abstraction within
Mozilla APIs. While I can certainly see the value of having a unified
view of mail, news, sitemaps, and so on, the Moz code at the time wasn't
really in a position to match up to the language in the press releases.

Not making any particular point here beyond connecting up to the MCF
heritage...

cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Jan 18, 2009, at 02:02, Sam Ruby wrote:

On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen
wrote:

On Jan 17, 2009, at 22:35, Shelley Powers wrote:

Generally, though, RDFa is based on reusing a set of attributes
already

existing in HTML5, and adding a few more.

Also, RDFa uses CURIEs which in turn use the XML namespace mapping
context.

I would assume no differences in the DOM based on XHTML or HTML.

The assumption is incorrect.

Please compare
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
and
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml

Same bytes, different media type.

The W3C Recommendation for DOM also describes a readonly attribute on
Attr named 'name'. Discuss.

I have added this to the test cases.

In the DOM API, you can use the namespace-unaware DOM Level 1 view to
make both cases look the same upon getting a parser-inserted value.
(This is, of course, totally against namespace-aware programming
practices, and in non-browser apps, the API might not even expose
qnames or higher-level technologies like RELAX NG or XPath can't
trigger on them.)

But it's too early to declare victory. Surely we want also scripted
setters that mutate the DOM into a state that could have been the
result of a parse.

Now we have tentatively seen that DOM Level 1 APIs seem to do what we
want. So let's try using setAttribute():

http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.html
The result looks the same as the HTML case earlier:
http://hsivonen.iki.fi/test/moz/xmlns-dom.html

But now, the XHTML side using the setter:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter.xhtml
...gives a result that is different from the parser-inserted attribute
XHTML:

http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml
Furthermore, the resulting DOM is no longer serializable as XML 1.0.

So let's move to a less intuitive case and use the namespace-aware
Level 2 setter while assuming the use of the namespace-unaware Level 1
getter:

http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.xhtml
Looks good compared to the parser-inserted XHTML case:
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml

But now, the HTML side is broken:
http://hsivonen.iki.fi/test/moz/xmlns-dom-setter-ns.html
vs.
http://hsivonen.iki.fi/test/moz/xmlns-dom.html

I put together a very crude demonstration of JavaScript access of a
specific RDFa attribute, about. It's temporary, but if you go to
my main web
page,http://realtech.burningbird.net, and look in the sidebar for
the click
me text, it will traverse each div element looking for an "about"
attribute,
and then pop up an alert with the value of the attribute. I would
use
console rather than alert, but I don't believe all browsers
support console,

yet.

This misses the point, because the inconsistency is with attributes
named

xmlns:foo.

There is a similar inconsistency in how xml:lang is handled. Discuss.

The xml:lang DOM inconsistency has lead to a situation where the
xml:lang/lang area in Validator.nu has has the highest incidence of
validator buts per spec sentence of all areas of HTML5. You've
reported at least one of those bugs. The amount of developer time
needed to get it right was ridiculously high.

fantasai recently wrote: “Unless you're working on a CSS layout engine
yourself, the level of detail, complex interactions with the rest of
CSS, and design and implementation constraints we need to deal with
here are more complicated than you can imagine.” (Source: http://fantasai.inkedblade.net/weblog/2009/layout-is-expensive/)

From my experience with Validator.nu (that doesn't even have a DOM!)
I think I can say: Unless you're working on a software product whose
code reuse between HTML and XHTML depends on the DOM Consistency
Design principle, the badness caused by violations of the DOM
Consistency Design principle is more complicated than you can imagine.
(Where 'you' is not you, Sam, but the generic English you.)

xml:lang was introduced by people who were designing for an XML
universe when it seemed that would be the way the world would go, so
they can be forgiven, and the WHATWG can clean up the mess. Likewise,
the syntax that the SVG WG chose made sense given that they were
designing for an XML world. It can be accepted as legacy, and HTML5
parser writers can spend time optimizing the conditional camel casing.

RDFa, on the other hand, was created by people who fully expected it
to be served as text/html, even though they called it something like
XHTML 1.1 plus RDFa instead of calling it HTML5. Furthermore, when
they saw they wanted to have RDFa in HTML5, too, instead of addressing
HTML issues then, they just continued pushing towards REC. It's easily
looks like this was done so that RDFa could be presented as a done
deal that HTML5 needs to deal with instead of something whose details
are negotiable. Creating a new mess that would have been easily
avoidable is not similarly forgivable. Al

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-17 Thread Ian Hickson

On Sat, 17 Jan 2009, Sam Ruby wrote:
> 
> But back to expectations.  I've seen references elsewhere to Ian being 
> booked through the end of this quarter.  I may have misheard, but in any 
> case, my point is the same: if this is awaiting something from Ian, it 
> will be prioritized and dealt with accordingly.

For what it's worth, my current plan running up to last call in October 
includes an item in April for me to go through all the use cases that have 
by that point been put forward in the data markup space, and to work out 
for each use case and on the aggregate:

1. Whether there is compelling evidence that users want that use case 
   addressed (e.g. whether there are successful companies addressing that 
   use case using proprietary solutions or ad-hoc extensions to HTML, or
   whether there are usability studies or some independent market research 
   showing demand from users, or whether it can be demonstrated that users 
   are avoiding the Web because it doesn't address this problem).

2. Whether the use case is being addressed well enough already (e.g. if 
   there are companies addressing this use case adequately, or whether the 
   current solutions really are just hacks with numerous problems).

3. What the requirements are for each use case.

4. What solutions are available to address these use cases.

5. For each solution, whether it addresses the requirements.

6. Whether the relevant implementors are interested in implementing 
   solutions for these use cases (e.g. whether authoring tools are willing 
   to expose the feature, whether validator writers want to check for the 
   correctness, whether browser vendors are willing to expose the relevant 
   UI, whether search engine companies are willing to use the data, or 
   whatever else might be appropriate).

The more use cases there are, the better informed the results will be.

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

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Sat, Jan 17, 2009 at 5:51 PM, Henri Sivonen  wrote:
> On Jan 17, 2009, at 22:35, Shelley Powers wrote:
>
>> Generally, though, RDFa is based on reusing a set of attributes already
>> existing in HTML5, and adding a few more.
>
> Also, RDFa uses CURIEs which in turn use the XML namespace mapping context.
>
>> I would assume no differences in the DOM based on XHTML or HTML.
>
> The assumption is incorrect.
>
> Please compare
> http://hsivonen.iki.fi/test/moz/xmlns-dom.html
> and
> http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml
>
> Same bytes, different media type.

The W3C Recommendation for DOM also describes a readonly attribute on
Attr named 'name'.  Discuss.

>> I put together a very crude demonstration of JavaScript access of a
>> specific RDFa attribute, about. It's temporary, but if you go to my main web
>> page,http://realtech.burningbird.net, and look in the sidebar for the click
>> me text, it will traverse each div element looking for an "about" attribute,
>> and then pop up an alert with the value of the attribute. I would use
>> console rather than alert, but I don't believe all browsers support console,
>> yet.
>
> This misses the point, because the inconsistency is with attributes named
> xmlns:foo.

There is a similar inconsistency in how xml:lang is handled.  Discuss.

> --
> Henri Sivonen
> hsivo...@iki.fi
> http://hsivonen.iki.fi/

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector





The assumption is incorrect.

Please compare
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
and
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml

Same bytes, different media type.

I put together a very crude demonstration of JavaScript access of a 
specific RDFa attribute, about. It's temporary, but if you go to my 
main web page,http://realtech.burningbird.net, and look in the 
sidebar for the click me text, it will traverse each div element 
looking for an "about" attribute, and then pop up an alert with the 
value of the attribute. I would use console rather than alert, but I 
don't believe all browsers support console, yet.


This misses the point, because the inconsistency is with attributes 
named xmlns:foo.


And I also said that we would have to address the issue of namespaces, 
which actually may require additional effort. I said that the addition 
of RDFa would mean the addition of some attributes, and we would have to 
deal with namespace issues. Just like the HTML5 working group is having 
to deal with namespaces with MathML and SVG. And probably the next dozen 
or so innovations that come along. That is the price for not having 
distributed extensibility.


One works the issues. I assume the same could be said of any many of the 
newer additions to HTML5. Are you then saying that this will be a 
showstopper, and there will never be either a workaround or compromise?


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 17, 2009, at 22:43, Shelley Powers wrote:


Henri Sivonen wrote:

On Jan 17, 2009, at 21:38, Shelley Powers wrote:

I'm not doubting the effort that went into getting MathML and SVG  
accepted. I've followed the effort associated with SVG since the  
beginning.


I'm not sure if the same procedure was also applied to the canvas  
object, as well as the SQL query capability. Will assume so.


Note that SVG, MathML and SQL have had different popularity  
trajectories in top four browser engines than RDF.


SVG is going up. At the time it was included in HTML5 (only to be  
commented out shortly thereafter), three of the top browser engines  
implemented SVG for retained-mode vector graphics and their SVG  
support was actively being improved. (One of the top four engines  
implemented VML, though.)


At the time MathML was included in HTML5, it was supported by Gecko  
with renewed investment into it as part of the Cairo migration.  
Also, Opera added some MathML features at that time. Thus, two of  
the top four engines had active MathML development going on.  
Further, one of the major MathML implementations is an ActiveX  
control for IE.


When SQL was included in HTML5, Apple (in WebKit) and Google (in  
Gears) had decided to use SQLite for this functionality. Even  
though Firefox doesn't have a Web-exposed database, Firefox also  
already ships with embedded SQLite. At that point it would have  
been futile for HTML5 to go against the flow of implementations.


The story of RDF is very different. Of the top four engines, only  
Gecko has RDF functionality. It was implemented at a time when RDF  
was a young W3C REC and stuff that were W3C RECs were implemented  
less critically than nowadays. Unlike SVG and MathML, the RDF code  
isn't actively developed (see hg logs). Moreover, the general  
direction seems to be away from using RDF data sources in Firefox  
internally.




Now wait a second, you're changing the parameters of the requirements.


I'm explaining how SVG, MathML and SQL are different from RDF(a) in a  
way that's very relevant to the practice of including stuff in the spec.


Before, the criteria was based on the DOM. Now you're saying that  
the browsers actually have to do with something with it.


Who is to say what the browsers will do with RDF in the future?


http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016045.html 
 is a message where one of the editors of RDFa mentions RDFa together  
with "client-side tools like Ubiquity". That Ubiquity is a Firefox  
extension rather than part of the core feature set is an  
implementation detail. I read this as envisioning browser-sensitivity  
to RDFa.


In addition, is that the criteria for pages on the web -- that every  
element in them has to result in different behaviors in browsers,  
only?


No. However, most of the time, when people publish HTML, they do it to  
elicit browser behavior when a user loads the HTML document in a  
browser.


Meanwhile, the feed example you gave--RSS 1.0--shows how the feed  
spec community knowingly moved away from RDF with RSS 2.0 and Atom.  
Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is  
treated as XML instead. If RSS 1.0 is evidence, it's evidence  
*against* RDF.


The point I'm making is that you set a precedent, and a good one I  
think: giving precedence to "not invented here". In other words,  
to not re-invent new ways of doing something, but to look for  
established processes, models, et al already in place,  
implemented, vetted, etc, that solve specific problems. Now that  
you have accepted a use case, Martin's, and we've established that  
RDFa solves the problem associated with the use case, the issue  
then becomes is there another data model already as vetted,  
documented, implemented that would better solve the problem.


Clearly, RDFa wasn't properly vetted--as far as the desire to  
deploy it in text/html goes--when the outcome was that it ended up  
using markup that doesn't parse into the DOM the same way in HTML  
and XML.


SVG and MathML were both created as XML, and hence were not vetted  
for text/html, either. And yet, here they are. Well, here they'll  
be, eventually.


Actually, the creators of MathML had the good sense and foresight to  
avoid name collisions with HTML even after Namespaces theoretically  
gave them a permission not to care.


Unlike the creators of RDFa, the creators of SVG weren't pushing for  
inclusion in HTML5 or saying that it's OK to serve their XML as text/ 
html--quite the contrary. And the integration would have been nicer if  
the SVG WG had had the same prudence as the Math WG.


Come to that -- I don't think the creators of SQL actually ever  
expected that someday SQL  queries would be initiated from HTML pages.



I don't see the creators of SQL asking for the inclusion of their  
stuff in HTML after building on another spec that is well-known to be  
trouble with HTML (Namespaces in XML in

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 17, 2009, at 22:35, Shelley Powers wrote:

Generally, though, RDFa is based on reusing a set of attributes  
already existing in HTML5, and adding a few more.


Also, RDFa uses CURIEs which in turn use the XML namespace mapping  
context.



I would assume no differences in the DOM based on XHTML or HTML.


The assumption is incorrect.

Please compare
http://hsivonen.iki.fi/test/moz/xmlns-dom.html
and
http://hsivonen.iki.fi/test/moz/xmlns-dom.xhtml

Same bytes, different media type.

I put together a very crude demonstration of JavaScript access of a  
specific RDFa attribute, about. It's temporary, but if you go to my  
main web page,http://realtech.burningbird.net, and look in the  
sidebar for the click me text, it will traverse each div element  
looking for an "about" attribute, and then pop up an alert with the  
value of the attribute. I would use console rather than alert, but I  
don't believe all browsers support console, yet.


This misses the point, because the inconsistency is with attributes  
named xmlns:foo.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-17 Thread L. David Baron

On Saturday 2009-01-17 22:25 +0200, Henri Sivonen wrote:
> The story of RDF is very different. Of the top four engines, only Gecko 
> has RDF functionality. It was implemented at a time when RDF was a young 
> W3C REC and stuff that were W3C RECs were implemented less critically 
> than nowadays.

Actually, the implementation was well underway *before* RDF was a
W3C REC, done by a team led by one of the designers of RDF.  In
other words, it was in Gecko because there were RDF advocates at
Netscape (although advocating, I think, a somewhat different RDF
than the current RDF recommendations).

Compare the dates on:
http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
http://www.w3.org/TR/1999/PR-rdf-schema-19990303/
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Frdf&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1998-01-01&maxdate=1999-01-01&cvsroot=%2Fcvsroot

-David

-- 
L. David Baron http://dbaron.org/
Mozilla Corporation   http://www.mozilla.com/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Sat, Jan 17, 2009 at 3:51 PM, Shelley Powers
 wrote:
> Sam Ruby wrote:
>>
>> On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
>>  wrote:
>>
>>>
>>> I propose that RDFa is the best solution to the use case Martin supplied,
>>> and we've shown how it is not a disruptive solution to HTML5.
>>>
>>
>> Others may differ, but my read is that the case is a strong one.  But
>> I will caution you that a little patience is in order.  SVG is not a
>> done deal yet.  I've been involved in a number of standards efforts,
>> and I've never seen a case of "proposed on a Saturday morning, decided
>> on a Saturday afternoon".  One demo is not conclusive.  Now you
>> mention that there exists a number of libraries.  I think that's
>> important.  Very important.  Possibly conclusive.
>>
>
> I am patient. Look at me? I make extensive use of both SVG and RDF -- that
> is the mark of a patient woman.
>>
>> But back to expectations.  I've seen references elsewhere to Ian being
>> booked through the end of this quarter.  I may have misheard, but in
>> any case, my point is the same: if this is awaiting something from
>> Ian, it will be prioritized and dealt with accordingly.  If, however,
>> some of the legwork is done for Ian, this may help accelerate the
>> effort.
>>
>
> First of all, whatever happens has to happen with either vetting by the
> RDF/RDFa folks, if not their active help. This is my way of saying, I'd be
> willing to do much of the legwork, but I want to make I don't represent RDFa
> incorrectly.
>
> Secondly, my finances have been caught up in the current downturn, and my
> first priority has to be on the hourly work and odd jobs I'm getting to keep
> afloat. Which means that I can't always guarantee 20+ hours a week on a
> task, nor can I travel. Anywhere.
>
> But if both are acceptable conditions, I'm willing to help with tasks.

I don't see any of that as being a problem.

>> Even little things may help a lot.  I know what I'm about to say may
>> be unpopular, but I'll say it anyway: take a few good examples of RDFa
>> and run them through Henri's validator.  The validator will helpfully
>> indicate exactly what areas of the spec would need to be updated in
>> order to accommodate RDFa.  The next step would be to take a look at
>> those sections.  If the update is obvious and straightforward, perhaps
>> nothing more is required.  But if not, researching into the options
>> and making recommendations may help.
>
> Tasks including this one.

Excellent.  Well, all except for the downturn thing, but you know what I mean.

In order to prevent any misunderstandings: it is not for me to assign
work.  In fact, nobody here is in such a position.  People simply note
things that need to be done, and do the ones that interest them, at
the pace at which they are able.

And communicate copiously.  If you need help in vetting, I am given to
understand that there is a small pocket of RDF enthusiasm in the W3C.
:-P

> Shelley

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Sam Ruby wrote:

On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
 wrote:
  

I propose that RDFa is the best solution to the use case Martin supplied,
and we've shown how it is not a disruptive solution to HTML5.



Others may differ, but my read is that the case is a strong one.  But
I will caution you that a little patience is in order.  SVG is not a
done deal yet.  I've been involved in a number of standards efforts,
and I've never seen a case of "proposed on a Saturday morning, decided
on a Saturday afternoon".  One demo is not conclusive.  Now you
mention that there exists a number of libraries.  I think that's
important.  Very important.  Possibly conclusive.
  
I am patient. Look at me? I make extensive use of both SVG and RDF -- 
that is the mark of a patient woman.

But back to expectations.  I've seen references elsewhere to Ian being
booked through the end of this quarter.  I may have misheard, but in
any case, my point is the same: if this is awaiting something from
Ian, it will be prioritized and dealt with accordingly.  If, however,
some of the legwork is done for Ian, this may help accelerate the
effort.
  
First of all, whatever happens has to happen with either vetting by the 
RDF/RDFa folks, if not their active help. This is my way of saying, I'd 
be willing to do much of the legwork, but I want to make I don't 
represent RDFa incorrectly.


Secondly, my finances have been caught up in the current downturn, and 
my first priority has to be on the hourly work and odd jobs I'm getting 
to keep afloat. Which means that I can't always guarantee 20+ hours a 
week on a task, nor can I travel. Anywhere.


But if both are acceptable conditions, I'm willing to help with tasks.

Even little things may help a lot.  I know what I'm about to say may
be unpopular, but I'll say it anyway: take a few good examples of RDFa
and run them through Henri's validator.  The validator will helpfully
indicate exactly what areas of the spec would need to be updated in
order to accommodate RDFa.  The next step would be to take a look at
those sections.  If the update is obvious and straightforward, perhaps
nothing more is required.  But if not, researching into the options
and making recommendations may help.

  

Tasks including this one.

Shelley


- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Henri Sivonen wrote:

On Jan 17, 2009, at 21:38, Shelley Powers wrote:

I'm not doubting the effort that went into getting MathML and SVG 
accepted. I've followed the effort associated with SVG since the 
beginning.


I'm not sure if the same procedure was also applied to the canvas 
object, as well as the SQL query capability. Will assume so.


Note that SVG, MathML and SQL have had different popularity 
trajectories in top four browser engines than RDF.


SVG is going up. At the time it was included in HTML5 (only to be 
commented out shortly thereafter), three of the top browser engines 
implemented SVG for retained-mode vector graphics and their SVG 
support was actively being improved. (One of the top four engines 
implemented VML, though.)


At the time MathML was included in HTML5, it was supported by Gecko 
with renewed investment into it as part of the Cairo migration. Also, 
Opera added some MathML features at that time. Thus, two of the top 
four engines had active MathML development going on. Further, one of 
the major MathML implementations is an ActiveX control for IE.


When SQL was included in HTML5, Apple (in WebKit) and Google (in 
Gears) had decided to use SQLite for this functionality. Even though 
Firefox doesn't have a Web-exposed database, Firefox also already 
ships with embedded SQLite. At that point it would have been futile 
for HTML5 to go against the flow of implementations.


The story of RDF is very different. Of the top four engines, only 
Gecko has RDF functionality. It was implemented at a time when RDF was 
a young W3C REC and stuff that were W3C RECs were implemented less 
critically than nowadays. Unlike SVG and MathML, the RDF code isn't 
actively developed (see hg logs). Moreover, the general direction 
seems to be away from using RDF data sources in Firefox internally.




Now wait a second, you're changing the parameters of the requirements. 
Before, the criteria was based on the DOM. Now you're saying that the 
browsers actually have to do with something with it.


Who is to say what the browsers will do with RDF in the future?

In addition, is that the criteria for pages on the web -- that every 
element in them has to result in different behaviors in browsers, only? 
What about other user agents?


That seems to me to be looking for RDFa sized holes and them throwing 
them into the criteria, specifically to trip up RDF, and hence, RDFa.



Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec 
community knowingly moved away from RDF with RSS 2.0 and Atom. 
Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is 
treated as XML instead. If RSS 1.0 is evidence, it's evidence 
*against* RDF.


The point I'm making is that you set a precedent, and a good one I 
think: giving precedence to "not invented here". In other words, to 
not re-invent new ways of doing something, but to look for 
established processes, models, et al already in place, implemented, 
vetted, etc, that solve specific problems. Now that you have accepted 
a use case, Martin's, and we've established that RDFa solves the 
problem associated with the use case, the issue then becomes is there 
another data model already as vetted, documented, implemented that 
would better solve the problem.


Clearly, RDFa wasn't properly vetted--as far as the desire to deploy 
it in text/html goes--when the outcome was that it ended up using 
markup that doesn't parse into the DOM the same way in HTML and XML.


SVG and MathML were both created as XML, and hence were not vetted for 
text/html, either. And yet, here they are. Well, here they'll be, 
eventually.


Come to that -- I don't think the creators of SQL actually ever expected 
that someday SQL  queries would be initiated from HTML pages.


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Henri Sivonen wrote:

On Jan 17, 2009, at 20:33, Dan Brickley wrote:


Good question. I for one expect RDFa to be accessible to Javascript.

http://code.google.com/p/rdfquery/wiki/Introduction -> 
http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is 
a nice example of code that does something useful in this way.



Does this code run the same way on both DOMs parsed from text/html and 
application/xhtml+xml in existing browsers without at any point 
branching on a condition that is a DOM difference between 
text/html-originated and application/xhtml+xml-originated DOMs?


I don't want to specifically look at just the one case, since it is not 
working in Safari, and IE8 and is too complex to debug right at this moment.


Generally, though, RDFa is based on reusing a set of attributes already 
existing in HTML5, and adding a few more. I would assume no differences 
in the DOM based on XHTML or HTML. The one issue that would occur has to 
do with the values assigned, not the syntax.


I put together a very crude demonstration of JavaScript access of a 
specific RDFa attribute, about. It's temporary, but if you go to my main 
web page, http://realtech.burningbird.net, and look in the sidebar for 
the click me text, it will traverse each div element looking for an 
"about" attribute, and then pop up an alert with the value of the 
attribute. I would use console rather than alert, but I don't believe 
all browsers support console, yet.


Access the page using Firefox, which is served the page as XHTML. Access 
it as IE8, which gets the page as HTML. You can tell the difference 
between my graphics are based in inline SVG, and will only show if the 
page is served as XHTML.


So, yes, with my quick, crude demonstration, DOM access is the same in 
both environments.


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
 wrote:
>
> I propose that RDFa is the best solution to the use case Martin supplied,
> and we've shown how it is not a disruptive solution to HTML5.

Others may differ, but my read is that the case is a strong one.  But
I will caution you that a little patience is in order.  SVG is not a
done deal yet.  I've been involved in a number of standards efforts,
and I've never seen a case of "proposed on a Saturday morning, decided
on a Saturday afternoon".  One demo is not conclusive.  Now you
mention that there exists a number of libraries.  I think that's
important.  Very important.  Possibly conclusive.

But back to expectations.  I've seen references elsewhere to Ian being
booked through the end of this quarter.  I may have misheard, but in
any case, my point is the same: if this is awaiting something from
Ian, it will be prioritized and dealt with accordingly.  If, however,
some of the legwork is done for Ian, this may help accelerate the
effort.

Even little things may help a lot.  I know what I'm about to say may
be unpopular, but I'll say it anyway: take a few good examples of RDFa
and run them through Henri's validator.  The validator will helpfully
indicate exactly what areas of the spec would need to be updated in
order to accommodate RDFa.  The next step would be to take a look at
those sections.  If the update is obvious and straightforward, perhaps
nothing more is required.  But if not, researching into the options
and making recommendations may help.

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 17, 2009, at 21:38, Shelley Powers wrote:

I'm not doubting the effort that went into getting MathML and SVG  
accepted. I've followed the effort associated with SVG since the  
beginning.


I'm not sure if the same procedure was also applied to the canvas  
object, as well as the SQL query capability. Will assume so.


Note that SVG, MathML and SQL have had different popularity  
trajectories in top four browser engines than RDF.


SVG is going up. At the time it was included in HTML5 (only to be  
commented out shortly thereafter), three of the top browser engines  
implemented SVG for retained-mode vector graphics and their SVG  
support was actively being improved. (One of the top four engines  
implemented VML, though.)


At the time MathML was included in HTML5, it was supported by Gecko  
with renewed investment into it as part of the Cairo migration. Also,  
Opera added some MathML features at that time. Thus, two of the top  
four engines had active MathML development going on. Further, one of  
the major MathML implementations is an ActiveX control for IE.


When SQL was included in HTML5, Apple (in WebKit) and Google (in  
Gears) had decided to use SQLite for this functionality. Even though  
Firefox doesn't have a Web-exposed database, Firefox also already  
ships with embedded SQLite. At that point it would have been futile  
for HTML5 to go against the flow of implementations.


The story of RDF is very different. Of the top four engines, only  
Gecko has RDF functionality. It was implemented at a time when RDF was  
a young W3C REC and stuff that were W3C RECs were implemented less  
critically than nowadays. Unlike SVG and MathML, the RDF code isn't  
actively developed (see hg logs). Moreover, the general direction  
seems to be away from using RDF data sources in Firefox internally.


Meanwhile, the feed example you gave--RSS 1.0--shows how the feed spec  
community knowingly moved away from RDF with RSS 2.0 and Atom.  
Furthermore, RSS 1.0 usually isn't parsed into an RDF graph but is  
treated as XML instead. If RSS 1.0 is evidence, it's evidence  
*against* RDF.


The point I'm making is that you set a precedent, and a good one I  
think: giving precedence to "not invented here". In other words, to  
not re-invent new ways of doing something, but to look for  
established processes, models, et al already in place, implemented,  
vetted, etc, that solve specific problems. Now that you have  
accepted a use case, Martin's, and we've established that RDFa  
solves the problem associated with the use case, the issue then  
becomes is there another data model already as vetted, documented,  
implemented that would better solve the problem.


Clearly, RDFa wasn't properly vetted--as far as the desire to deploy  
it in text/html goes--when the outcome was that it ended up using  
markup that doesn't parse into the DOM the same way in HTML and XML.


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Ian Hickson wrote:

On Sat, 17 Jan 2009, Sam Ruby wrote:
  

Shelley Powers wrote:

So, why accept that we have to use MathML in order to solve the 
problems of formatting mathematical formula? Why not start from 
scratch, and devise a new approach?
  

Ian explored (and answered) that here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

Key to Ian's decision was the importance of DOM integration for this 
vocabulary.  If DOM integration is essential for RDFa, then perhaps the 
same principles apply.  If not, perhaps some other principles may apply.



Sam's point here bears repeating, because there seems to be an impression 
that we took on SVG and MathML without any consideration, while RDF is 
getting an unfair reception.


On the contrary, SVG and MathML got the same reception. For MathML, for 
instance, a number of options were very seriously considered, most notably 
LaTeX. For SVG, we considered a variety of options including VML.


I would encourage people to read the e-mail Sam cited:

   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

It's long, but the start of it is a summary of what was considered and 
shows that the same process derived from use cases was used for SVG and 
MathML as is being used on this thread here.


  
I'm not doubting the effort that went into getting MathML and SVG 
accepted. I've followed the effort associated with SVG since the beginning.


I'm not sure if the same procedure was also applied to the canvas 
object, as well as the SQL query capability. Will assume so.


The point I'm making is that you set a precedent, and a good one I 
think: giving precedence to "not invented here". In other words, to not 
re-invent new ways of doing something, but to look for established 
processes, models, et al already in place, implemented, vetted, etc, 
that solve specific problems. Now that you have accepted a use case, 
Martin's, and we've established that RDFa solves the problem associated 
with the use case, the issue then becomes is there another data model 
already as vetted, documented, implemented that would better solve the 
problem.


I propose that RDFa is the best solution to the use case Martin 
supplied, and we've shown how it is not a disruptive solution to HTML5.


The fact that it is based on RDF, a mature, well documented, widely used 
model with many different implementations is a perk.


Shelley

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


On Jan 17, 2009, at 20:33, Dan Brickley wrote:


Good question. I for one expect RDFa to be accessible to Javascript.

http://code.google.com/p/rdfquery/wiki/Introduction -> http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html 
 is a nice example of code that does something useful in this way.



Does this code run the same way on both DOMs parsed from text/html and  
application/xhtml+xml in existing browsers without at any point  
branching on a condition that is a DOM difference between text/html- 
originated and application/xhtml+xml-originated DOMs?


--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Sam Ruby wrote:

On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley  wrote:
  

On 17/1/09 19:27, Sam Ruby wrote:


On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
  wrote:
  

The debate about RDFa highlights a disconnect in the decision making
related
to HTML5.


Perhaps.  Or perhaps not.  I am far from an apologist for Hixie, (nor
for that matter and I a strong advocate for RDF), but I offer the
following question and observation.

  

The purpose behind RDFa is to provide a way to embed complex information
into a web document, in such a way that a machine can extract this
information and combine it with other data extracted from other web
pages.
It is not a way to document private data, or data that is meant to be
used
by some JavaScript-based application. The sole purpose of the data is for
external extraction and combination.


So, I take it that it isn't essential that RDFa information be
included in the DOM?  This is not rhetorical: I honestly don't know
the answer to this question.
  

Good question. I for one expect RDFa to be accessible to Javascript.

http://code.google.com/p/rdfquery/wiki/Introduction ->
http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice
example of code that does something useful in this way.



The fact that this works anywhere at all today implies that little, if
any, changes to browsers is required in order to support this.  Is
that a fair statement?

I've not taken a look at the code, but have taken a quick glance at
the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome
1.0.154.43, Opera 9.63, and Firefox 3.0.5.

The page is different (as in less functional) under IE8 and Safari.
Is there something that they need to do which is not already covered
in the HTML5 specification in order to support this?
  


I would think we would have to go through the code to see what this 
specific instance of client-side access of the RDFa isn't working. The 
debugger I'm using with IE8 shows the problem is occuring in the jQuery 
code, not necessarily anything specific to the RDFa plugin.


I know other JavaScript libraries that work with RDFa work, at least 
with Safari. For instance:


http://www.w3.org/2006/07/SWD/RDFa/impl/js/

Since this library was vetted for IE7, would assume it would work for 
IE8, too.


Of course, the RDFa attributes aren't incorporated into HTML5, which 
means their use would result in an invalid document. And of course, if 
they were incorporated, the issue of namespace for them would have to be 
addressed as namespaces were for MathML and SVG.


Shelley

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-17 Thread Ian Hickson

On Sat, 17 Jan 2009, Sam Ruby wrote:
> Shelley Powers wrote:
> >
> > So, why accept that we have to use MathML in order to solve the 
> > problems of formatting mathematical formula? Why not start from 
> > scratch, and devise a new approach?
> 
> Ian explored (and answered) that here:
> 
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html
> 
> Key to Ian's decision was the importance of DOM integration for this 
> vocabulary.  If DOM integration is essential for RDFa, then perhaps the 
> same principles apply.  If not, perhaps some other principles may apply.

Sam's point here bears repeating, because there seems to be an impression 
that we took on SVG and MathML without any consideration, while RDF is 
getting an unfair reception.

On the contrary, SVG and MathML got the same reception. For MathML, for 
instance, a number of options were very seriously considered, most notably 
LaTeX. For SVG, we considered a variety of options including VML.

I would encourage people to read the e-mail Sam cited:

   http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

It's long, but the start of it is a summary of what was considered and 
shows that the same process derived from use cases was used for SVG and 
MathML as is being used on this thread here.

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

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley  wrote:
> On 17/1/09 19:27, Sam Ruby wrote:
>>
>> On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
>>   wrote:
>>>
>>> The debate about RDFa highlights a disconnect in the decision making
>>> related
>>> to HTML5.
>>
>> Perhaps.  Or perhaps not.  I am far from an apologist for Hixie, (nor
>> for that matter and I a strong advocate for RDF), but I offer the
>> following question and observation.
>>
>>> The purpose behind RDFa is to provide a way to embed complex information
>>> into a web document, in such a way that a machine can extract this
>>> information and combine it with other data extracted from other web
>>> pages.
>>> It is not a way to document private data, or data that is meant to be
>>> used
>>> by some JavaScript-based application. The sole purpose of the data is for
>>> external extraction and combination.
>>
>> So, I take it that it isn't essential that RDFa information be
>> included in the DOM?  This is not rhetorical: I honestly don't know
>> the answer to this question.
>
> Good question. I for one expect RDFa to be accessible to Javascript.
>
> http://code.google.com/p/rdfquery/wiki/Introduction ->
> http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a nice
> example of code that does something useful in this way.

The fact that this works anywhere at all today implies that little, if
any, changes to browsers is required in order to support this.  Is
that a fair statement?

I've not taken a look at the code, but have taken a quick glance at
the output using IE8.0.7000.0 beta, Safari 3.2.1/Windows, Chrome
1.0.154.43, Opera 9.63, and Firefox 3.0.5.

The page is different (as in less functional) under IE8 and Safari.
Is there something that they need to do which is not already covered
in the HTML5 specification in order to support this?

- Sam Ruby

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector


Dan Brickley wrote:

On 17/1/09 19:27, Sam Ruby wrote:

On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
  wrote:
The debate about RDFa highlights a disconnect in the decision making 
related

to HTML5.


Perhaps.  Or perhaps not.  I am far from an apologist for Hixie, (nor
for that matter and I a strong advocate for RDF), but I offer the
following question and observation.

The purpose behind RDFa is to provide a way to embed complex 
information

into a web document, in such a way that a machine can extract this
information and combine it with other data extracted from other web 
pages.
It is not a way to document private data, or data that is meant to 
be used
by some JavaScript-based application. The sole purpose of the data 
is for

external extraction and combination.


So, I take it that it isn't essential that RDFa information be
included in the DOM?  This is not rhetorical: I honestly don't know
the answer to this question.


Good question. I for one expect RDFa to be accessible to Javascript.

http://code.google.com/p/rdfquery/wiki/Introduction -> 
http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a 
nice example of code that does something useful in this way.


cheers,

Dan



I agree, and appreciate Dan for pointing out a specific instance of use.

Apologies for not making the assertion explicit.

Shelley

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

2009-01-17 Thread Dan Brickley


On 17/1/09 19:27, Sam Ruby wrote:

On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
  wrote:

The debate about RDFa highlights a disconnect in the decision making related
to HTML5.


Perhaps.  Or perhaps not.  I am far from an apologist for Hixie, (nor
for that matter and I a strong advocate for RDF), but I offer the
following question and observation.


The purpose behind RDFa is to provide a way to embed complex information
into a web document, in such a way that a machine can extract this
information and combine it with other data extracted from other web pages.
It is not a way to document private data, or data that is meant to be used
by some JavaScript-based application. The sole purpose of the data is for
external extraction and combination.


So, I take it that it isn't essential that RDFa information be
included in the DOM?  This is not rhetorical: I honestly don't know
the answer to this question.


Good question. I for one expect RDFa to be accessible to Javascript.

http://code.google.com/p/rdfquery/wiki/Introduction -> 
http://rdfquery.googlecode.com/svn/trunk/demos/markup/markup.html is a 
nice example of code that does something useful in this way.


cheers,

Dan

--
http://danbri.org/

Re: [whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
 wrote:
> The debate about RDFa highlights a disconnect in the decision making related
> to HTML5.

Perhaps.  Or perhaps not.  I am far from an apologist for Hixie, (nor
for that matter and I a strong advocate for RDF), but I offer the
following question and observation.

> The purpose behind RDFa is to provide a way to embed complex information
> into a web document, in such a way that a machine can extract this
> information and combine it with other data extracted from other web pages.
> It is not a way to document private data, or data that is meant to be used
> by some JavaScript-based application. The sole purpose of the data is for
> external extraction and combination.

So, I take it that it isn't essential that RDFa information be
included in the DOM?  This is not rhetorical: I honestly don't know
the answer to this question.

> So, why accept that we have to use MathML in order to solve the problems of
> formatting mathematical formula? Why not start from scratch, and devise a
> new approach?

Ian explored (and answered) that here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-April/014372.html

Key to Ian's decision was the importance of DOM integration for this
vocabulary.  If DOM integration is essential for RDFa, then perhaps
the same principles apply.  If not, perhaps some other principles may
apply.

- Sam Ruby

[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector

The debate about RDFa highlights a disconnect in the decision making 
related to HTML5.

The purpose behind RDFa is to provide a way to embed complex information 
into a web document, in such a way that a machine can extract this 
information and combine it with other data extracted from other web 
pages. It is not a way to document private data, or data that is meant 
to be used by some JavaScript-based application. The sole purpose of the 
data is for external extraction and combination.

An earlier email between Martin Atkins and Ian Hickson had the following:

"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."

It would seem that Ian agrees with a need to both a) provide a way to 
document complex information in a consistent, machine readable form and 
that b) the purpose of this data is for external consumption, rather 
than internal use. Where the disconnect comes in is he believes that 
RDF, and the web page serialization technique, RDFa, are only one of a 
set of possible solutions.

Yet at the same time, he references how the MathML and SVG people 
provide sufficient use cases to justify the inclusion of both of these 
into HTML5. But what is MathML. What does it solve? A way to include 
mathematical formula into a document in a formatted manner. What is SVG? 
A way to embed vector graphics into a web page, in such a way that the 
individual elements described by the graphics can become part of the 
overall DOM.

So, why accept that we have to use MathML in order to solve the problems 
of formatting mathematical formula? Why not start from scratch, and 
devise a new approach?

So, why accept that we have to use SVG in order to solve the problems of 
vector graphics? Why not start from scratch, and devise a new approach?

Come to think of it, I think we should also question the use of the 
canvas element. After all, if the problem set is that we need the 
ability to animate graphics in a web page using a non-proprietary 
technology, then wouldn't something like SVG work for this purpose? 
Isn't the canvas element redundant? But then, perhaps we should start 
over from the beginning and just create a new graphics capability from 
scratch, and reject both canvas and SVG.

We don't reject MathML, though. Neither do we reject SVG or canvas. Or 
any other of a number of entities being included in HTML5, including 
SQL. Why? Because they have a history of use, extensive documentation as 
to purpose and behavior, and there are a considerable number of 
implementations that support the specifications. It doesn't make sense 
to start from scratch. It makes more sense to make use of what already 
works.

I have to ask, then: why do we isolate RDF, and RDFa for special 
handling? If we can accept that SQL is a natural database query 
mecha

Re: [whatwg] RDFa

2008-09-10 Thread Kristof Zelechovski

I dare remind you that the recommended place for RDFa-related arguments is
the wiki.  This is a large topic with various diverging opinions and it is
hard to track issues without looping in a mailing list discussion.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben Adida
Sent: Wednesday, September 10, 2008 12:30 AM
To: Silvia Pfeiffer
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] RDFa

Silvia Pfeiffer wrote:
> Make a technical argument that is
> conclusive and people will listen.

We have already done that at great length, using explicit examples, on
this very mailing list. We will continue to do so, but please take into
consideration that we have already done quite a bit of that.

-Ben

Re: [whatwg] RDFa

Silvia Pfeiffer wrote:
> I don't see it as such. HTML5 is analysing the situation from all
> aspects with a view of making sure the aims and tradition of HTML are
> being followed.

I respectfully, but strongly, disagree. There have been significant
deviations from the "tradition" of HTML. HTML was meant to be a web of
documents, and it is being transformed, in large part by HTML5, into a
web of applications.

I'm not saying that's a bad thing (in fact a number of HTML5 additions
are, IMO, particularly good), but I don't think HTML5 can claim to be
"in the tradition of HTML" anymore than a number of other groups.

It is worth noting, in particular, that RDFa-in-XHTML1.1 was
co-developed by the XHTML Working Group at the W3C, including specific
individuals who have been involved in the development of HTML and CSS
since very early versions. It would be untrue to say that HTML5 is the
locus of HTML "tradition," as there are many different interpretations
as to what that tradition is and what the future of HTML should be.

> Make a technical argument that is
> conclusive and people will listen.

We have already done that at great length, using explicit examples, on
this very mailing list. We will continue to do so, but please take into
consideration that we have already done quite a bit of that.

-Ben

Re: [whatwg] RDFa

2008-09-09 Thread Silvia Pfeiffer

On Wed, Sep 10, 2008 at 7:12 AM, Ben Adida <[EMAIL PROTECTED]> wrote:
> In general, I find it surprising that HTML5 wants to reinvent
> everything, rather than at least partially rely on work done in other
> groups.

I don't see it as such. HTML5 is analysing the situation from all
aspects with a view of making sure the aims and tradition of HTML are
being followed. Assessing how others have solved the issue is part of
that. But you cannot assume by default that what works in other
situations will also work for HTML5. Make a technical argument that is
conclusive and people will listen.

In fact - and this is my personal opinion - the suggestion of a
metadata attribute along similar lines of the style attribute and a
similar external metadata document along the lines of CSS follow a
known and tested path in HTML. In comparison, throwing in a multitude
of new attributes that will inevitably be used in the wrong way seems
to provide only a limited solution.

Regards,
Silvia.

Re: [whatwg] RDFa

On Tue, 9 Sep 2008, Ian Hickson wrote:
> On Tue, 9 Sep 2008, Ben Adida wrote:
> > Ian Hickson wrote:
> > > Note however that I do not expect the namespace issue to materially 
> > > affect 
> > > the RDFa feedback; I'm sure there are many ways of addressing the problem 
> > > space of RDF that do not involve having to use namespace prefixes.
> > 
> > You would be incorrect to make this assumption.
> >
> > Much work has already been done on RDFa in XHTML1.1, and to have the 
> > HTML5 approach do something completely incompatible would be a serious 
> > problem.
> 
> Unless it is expected that RDFa usage in XHTML 1.1 is going to be higher 
> than whatever we put into HTML5, losses from incompatibility can be offset 
> by gains in usability. Naturally though, we shouldn't 

...introduce gratuitous differences that don't have a significant benefit.

I guess I thought it went without saying. ;-)

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

Re: [whatwg] RDFa

On Tue, 9 Sep 2008, Ben Adida wrote:
>
> Ian Hickson wrote:
> > In the WHATWG the editor (me, for HTML5) makes the decisions,
> 
> How does that jive with the W3C process, which I thought HTML5 was now 
> following given the joint work with W3C?

The W3C HTML working group and the WHATWG group are working together to 
produce a joint specification, but they have their own distinct processes.

Discussion of the W3C process is out of scope for this mailing list, 
however, since this is the WHATWG list.

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

Re: [whatwg] RDFa

On Tue, 9 Sep 2008, Ben Adida wrote:
> Ian Hickson wrote:
> > Note however that I do not expect the namespace issue to materially affect 
> > the RDFa feedback; I'm sure there are many ways of addressing the problem 
> > space of RDF that do not involve having to use namespace prefixes.
> 
> You would be incorrect to make this assumption.
>
> Much work has already been done on RDFa in XHTML1.1, and to have the 
> HTML5 approach do something completely incompatible would be a serious 
> problem.

Unless it is expected that RDFa usage in XHTML 1.1 is going to be higher 
than whatever we put into HTML5, losses from incompatibility can be offset 
by gains in usability. Naturally though, we shouldn't 

> In general, I find it surprising that HTML5 wants to reinvent 
> everything, rather than at least partially rely on work done in other 
> groups.

We don't want to reinvent everything. Indeed, the vast majority of the 
features in HTML5 are merely defining in more detail features that 
existing prior to HTML5, or are reusing existing standards in conjunction 
with minimal new syntax or API surface area.

With the RDFa feedback, I have yet to carefully study the requirements and 
proposals, so I cannot say if there is an existing solution that can just 
be reused wholesale. Certainly, existing technologies must inform whatever 
decisions we make; however, we have a responsibility to specify designs 
that are as technically sound and as usable as we are able to make them.

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

Re: [whatwg] RDFa

Ian Hickson wrote:
> In the WHATWG the editor (me, for HTML5) makes the decisions,

How does that jive with the W3C process, which I thought HTML5 was now
following given the joint work with W3C?

-Ben

Re: [whatwg] RDFa

Ian Hickson wrote:
> Note however that I do not expect the namespace issue to materially affect 
> the RDFa feedback; I'm sure there are many ways of addressing the problem 
> space of RDF that do not involve having to use namespace prefixes.

You would be incorrect to make this assumption.

Much work has already been done on RDFa in XHTML1.1, and to have the
HTML5 approach do something completely incompatible would be a serious
problem.

In general, I find it surprising that HTML5 wants to reinvent
everything, rather than at least partially rely on work done in other
groups.

-Ben

Re: [whatwg] RDFa

On Tue, 9 Sep 2008, Philipp Serafin wrote:
>
> Please correct me if I'm wrong here, but it looks to me as if RDFa uses 
> namespaced identifiers nowhere outside attribute values right now. So 
> couldn't you just introduce a "rdf specific" namespacing system for 
> example like eRDF does[1]? This way, RDF parsers could still look up 
> metainformation about RDF properties while RDF-unaware agents could 
> parse the attribute values as simple text.

Oh I'm sure there are plenty of ways to handle the RDF problem space in 
text/html, assuming we establish that as being a problem worth solving in 
HTML5. I haven't had a chance to look closely at the feedback on RDF yet, 
there are a number of topic areas, in particular the forms, video, and 
offline features, that have a higher priority and have to be dealt with 
first.

On Tue, 9 Sep 2008, Ben Adida wrote:
> >
> > Both introducing a namespace prefix processing model and introducing 
> > DOM inconsistencies at the XML/HTML boundary intentionally are simply 
> > not an option in WHATWG specs at this point.
> 
> What is the evidence you have for making this decision, specifically 
> what is the evidence you have for conflating past issues with this one? 

A lot of the data on namespace issues is collected here:

   http://wiki.whatwg.org/wiki/Namespace_confusion

The edict against DOM inconsistency is primarily borne of feedback from 
browser vendors.

> Who gets to make this decision?

In the WHATWG the editor (me, for HTML5) makes the decisions, which can 
then be overriden by the core membership (as defined at the bottom of the 
charter) if they disagree with it:

   http://www.whatwg.org/charter

> What is the process by which such a decision is made?

The WHATWG process is described in the FAQ:

   http://wiki.whatwg.org/wiki/FAQ#The_WHATWG_Process

Note however that I do not expect the namespace issue to materially affect 
the RDFa feedback; I'm sure there are many ways of addressing the problem 
space of RDF that do not involve having to use namespace prefixes.

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

Re: [whatwg] RDFa

Ian Hickson wrote:
> Both introducing a namespace prefix processing model and introducing DOM 
> inconsistencies at the XML/HTML boundary intentionally are simply not an 
> option in WHATWG specs at this point.

What is the evidence you have for making this decision, specifically
what is the evidence you have for conflating past issues with this one?
Who gets to make this decision? What is the process by which such a
decision is made?

(Note that the XML/HTML DOM consistency issue is not real, so it's worth
focusing on the prefix issue.)

-Ben

Re: [whatwg] RDFa

Philipp Serafin wrote:
> Please correct me if I'm wrong here, but it looks to me as if RDFa
> uses namespaced identifiers nowhere outside attribute values right
> now. So couldn't you just introduce a "rdf specific" namespacing

Yes, that is exactly what we're considering for non-XML HTML.

-Ben

[whatwg] RDFa

2008-09-09 Thread Philipp Serafin

Please correct me if I'm wrong here, but it looks to me as if RDFa
uses namespaced identifiers nowhere outside attribute values right
now. So couldn't you just introduce a "rdf specific" namespacing
system for example like eRDF does[1]? This way, RDF parsers could
still look up metainformation about RDF properties while RDF-unaware
agents could parse the attribute values as simple text.

[1] http://research.talis.com/2005/erdf/wiki/Main/RdfInHtml#schemas

On Tue, Sep 9, 2008 at 10:58 AM, Ian Hickson <[EMAIL PROTECTED]> wrote:

> Both introducing a namespace prefix processing model and introducing DOM
> inconsistencies at the XML/HTML boundary intentionally are simply not an
> option in WHATWG specs at this point. Experience borne out of mechanisms
> that have had these characteristics [1] has shown these problems to be
> simply unacceptable for a Web authoring-level specification. This is
> feedback I have received from browser vendors and authors a lot.
>
> ([1] e.g. XML namespaces, which has the former characteristic when used in
> XHTML1 documents processed as XML and the latter characteristic when used
> in XHTML documents processed as HTML4.)
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Re: [whatwg] RDFa

On Mon, 8 Sep 2008, Elliotte Harold wrote:
> Henri Sivonen wrote:
> > 
> > The DOM consistency issue is that the xmlns attributes are DOM-wise 
> > different in text/html and application/xhtml+xml due to legacy 
> > reasons. The attribute that reads xmlns:cc="..." is represented 
> > differently in the DOM when the serialization was text/html than when 
> > it was application/xhtml+xml. We can't make xmlns:foo='...' conforming 
> > on HTML elements without either violating the DOM Consistency design 
> > principle (bad) or introducing namespace processing into HTML5 parsing 
> > (also bad).
> 
> FWIW, I think introducing namespace processing into HTML 5 parsing is 
> the lesser evil here. I think it is substantially less bad than an 
> inconsistent DOM.

Both introducing a namespace prefix processing model and introducing DOM 
inconsistencies at the XML/HTML boundary intentionally are simply not an 
option in WHATWG specs at this point. Experience borne out of mechanisms 
that have had these characteristics [1] has shown these problems to be 
simply unacceptable for a Web authoring-level specification. This is 
feedback I have received from browser vendors and authors a lot.

([1] e.g. XML namespaces, which has the former characteristic when used in 
XHTML1 documents processed as XML and the latter characteristic when used 
in XHTML documents processed as HTML4.)

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

Re: [whatwg] RDFa

2008-09-08 Thread Elliotte Harold


Henri Sivonen wrote:

On Aug 24, 2008, at 00:15, Ben Adida wrote:


The DOM consistency issue is that the xmlns attributes are DOM-wise 
different in text/html and application/xhtml+xml due to legacy reasons. 
The attribute that reads xmlns:cc="..." is represented differently in 
the DOM when the serialization was text/html than when it was 
application/xhtml+xml. We can't make xmlns:foo='...' conforming on HTML 
elements without either violating the DOM Consistency design principle 
(bad) or introducing namespace processing into HTML5 parsing (also bad).




FWIW, I think introducing namespace processing into HTML 5 parsing is 
the lesser evil here. I think it is substantially less bad than an 
inconsistent DOM.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Re: [whatwg] RDFa discussion

2008-08-31 Thread ddailey

Thanks. Your advice here, seems, fundamentally, like a most sensible choice. 
96 (or so*) semantic primitives (e.g. act (generic verb marker), thing and 
essence (generic noun markers), value(quality and magnitude), able/possible, 
universal and existential, poset (brings comparatives for ancestry, modal 
logic, ethics and spatial process) , person, this/that/yonder (as in 
Navajo -- enables deixis for person, time, evaluative and space modalities), 
need, sense,  and think; adjectival mark, gender, negation (incl. voidance & 
reflection), time (including past present and poset/hypothetical), space 
(including those which are metric but non-dimensional, but certainly 
including directional vectors in nonmetric spaces flavored by vector 
bundles) ,  iteration/extrapolation/completion (for continuative aspects of 
verbs), number,  change, the SFOL conjunctions plus preventative and 
causitive, ...,, plus an appropriate syntax (parentheses plus 
crossreferences:  i.,e., , graphs), I think, suffices to encode most of the 
non-molecular cognitive reality of humans (and several hypothetical 
categories of sentient species ).  The molecular world populated by halibut, 
coca-cola, guitars and rhinos is likely to require an open and extensible 
format, but plain old human thought as expressed in philosophy, teleology 
and mechanism is likely not to require much more, until, perhaps, we mutate. 
Of course the expressive power of such a system includes undecidable 
subsystems and likely allows the derivation of contradictions, but humans 
have generally not been known to implode under exposure to simple 
contradictions, so that need not be a problem for inference engines.


So I think a proper full-bodied inferential realm can indeed be hashed out. 
Providing a forum for that to be done, off-list,  seems great since the 
whatwgers often seem to use "semantics" to refer to something rather 
different than "meaning" in the sense of human linguistics.


cheers,
David
*I rather doubt that the number is prime, though determining that has been 
shown to be NP-complete for arbitrary monolingual dictionaries.


- Original Message - 
From: "Ian Hickson" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Friday, August 29, 2008 4:50 PM
Subject: [whatwg] RDFa discussion




It seems that there is a lot of discussion here but I haven't really seen
much progress. Part of the problem seems to be that there are some pretty
fundamental disagreements on what we are trying to do and whether anyone
cares to do it. :-)

In order to better document this back-and-forth, and to reduce the total
number of e-mails I will have to reply to when I eventually deal with this
topic, I would like to invite people to place the goals and requirements
of the technologies being proposed on this wiki page:

  http://wiki.whatwg.org/wiki/Generic_Metadata_Mechanisms

I would then like people to place their arguments pro and con each point
on that same page. I have tried to put in some placeholder arguments to
show how that might work.

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

Re: [whatwg] RDFa statement consistency

Plain text loses context under copy and paste as well.  I doubt it is
possible to express complex cultural phenomena without context of any kind.
When you paste a fragment of another document, you usually have to provide
some information about the context of the fragment.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Julian Reschke
Sent: Saturday, August 30, 2008 1:25 AM
To: Henri Sivonen
Cc: Ben Adida; whatwg@lists.whatwg.org; 'Manu Sporny'; Kristof Zelechovski
Subject: Re: [whatwg] RDFa statement consistency


>> I like GRDDL, too, but it has problems with respect to scaling similar 
>> to microformats. Things will get complicated when you want to combine 
>> statements from different vocabularies on the same page.
> 
> The completely prefixless microformat naming approach isn't good when 
> different microformats overlap and common words have been allocated 
> badly. It works if you can decide that all classes that are on 
> descendants of a class identifying a format root belong to that format 
> (i.e. the subtree root is effectively the prefix).

Yes. But in that case the format is fragile under copy&paste, just as 
prefix-based approaches.

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Julian Reschke


Henri Sivonen wrote:
If I've understood history correctly, introducing Namespaces into XML 
was primarily a requirement stipulated by the RDF community. XML got


Pointer, please?


http://lists.w3.org/Archives/Public/semantic-web/2007Dec/0116.html


Thanks.

I like GRDDL, too, but it has problems with respect to scaling similar 
to microformats. Things will get complicated when you want to combine 
statements from different vocabularies on the same page.


The completely prefixless microformat naming approach isn't good when 
different microformats overlap and common words have been allocated 
badly. It works if you can decide that all classes that are on 
descendants of a class identifying a format root belong to that format 
(i.e. the subtree root is effectively the prefix).


Yes. But in that case the format is fragile under copy&paste, just as 
prefix-based approaches.



...

Browsers don't
need to do anything (except make the attributes available in the DOM,
which they would probably do anyways.)
I'm getting mixed signals about the extent to which RDFa in 
envisioned to be browser-sensitive. Weren't browsers supposed to do 
cool stuff with it according to some emails in this thread?

...


Browsers are not "supposed" to do with RDFa anymore than, for 
instance, with microformats.



I've seen Mozilla Ubiquity referred to several times in this 
thread--presumably with the implication that something like Mozilla 
Ubiquity should be RDFa-based. That would be more than just ignoring 
attributes. (As far as I can tell, Ubiquity is not RDFa-based.)


Ubiquity is a plugin.

So again, nobody is asking the UA vendors *right now* to do something 
with it -- just like nobody is asking for native Microformats support.


BR, Julian

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Dan Brickley


Henri Sivonen wrote:

On Aug 29, 2008, at 11:11, Julian Reschke wrote:


Henri Sivonen wrote:

I don't believe that is the case.
If I've understood history correctly, introducing Namespaces into XML 
was primarily a requirement stipulated by the RDF community. XML got


Pointer, please?


http://lists.w3.org/Archives/Public/semantic-web/2007Dec/0116.html


W3C Members (or invited experts with the right permissions) can read 
more of the back story in the original XML WG archives.


See http://lists.w3.org/Archives/Member/w3c-xml-wg/1998Jan/0034.html
'URGENT: Proposal to modify or delay XML 1.0 Recommendation', From: Jon 
Bosak, 12 Jan 1998. This points to a paper,

'Turning XML into a Universal Syntax for Web Data Formats'
http://www.w3.org/Member/Meeting/98JanAC/xml-req.html that was put 
before the Jan 1998 W3C AC Meeting in San Jose. I think it's reasonable 
to share the abstract here: "Concern is shared by members of the RDF, 
SMIL and Math working groups, and the W3C architecture domain staff, 
that the XML 1.0 Proposed Recommendation of 8Dec97 does not address the 
needs as a common base for the transmission of machine-understandable 
data.".


cheers,

Dan

[whatwg] RDFa discussion

2008-08-29 Thread Ian Hickson


It seems that there is a lot of discussion here but I haven't really seen 
much progress. Part of the problem seems to be that there are some pretty 
fundamental disagreements on what we are trying to do and whether anyone 
cares to do it. :-)

In order to better document this back-and-forth, and to reduce the total 
number of e-mails I will have to reply to when I eventually deal with this 
topic, I would like to invite people to place the goals and requirements 
of the technologies being proposed on this wiki page:

   http://wiki.whatwg.org/wiki/Generic_Metadata_Mechanisms

I would then like people to place their arguments pro and con each point 
on that same page. I have tried to put in some placeholder arguments to 
show how that might work.

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

Re: [whatwg] RDFa statement consistency

WHATWG cannot purge existing ignored elements and properties but it can try
avoiding adding new ones.
Besides, I wonder if the promoter of the DFN element make it clear that he
expected it to be ignored by the browser, as is the case with RDFa.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Toby A Inkster
Sent: Friday, August 29, 2008 10:28 PM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] RDFa statement consistency

Kristof Zelechovski wrote:

> The goal of the specification is to provide a set of rules that  
> conformant
> user agents must obey out of the box, without any extensions.   
> Features that
> are supposed to be ignored do not make good candidates for  
> including in the
> specification, except as extensions to HTML that are explicitly  
> supported.

The HTML 5 spec already includes the many features which browsers  
currently (mostly) ignore - the  tag, the "type" attribute on  
most links and so on. The fact that HTML includes a  element  
doesn't mean that every browser has to have a built in dictionary for  
storing all the definitions people collect on the web, but the  
element is there for those people who want to use it. Browsers  
*could* do something useful with  if they liked, but none so far  
seem to have done so.

-- 
Toby A Inkster
<mailto:[EMAIL PROTECTED]>
<http://tobyinkster.co.uk>

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Toby A Inkster


Kristof Zelechovski wrote:

The goal of the specification is to provide a set of rules that  
conformant
user agents must obey out of the box, without any extensions.   
Features that
are supposed to be ignored do not make good candidates for  
including in the
specification, except as extensions to HTML that are explicitly  
supported.


The HTML 5 spec already includes the many features which browsers  
currently (mostly) ignore - the  tag, the "type" attribute on  
most links and so on. The fact that HTML includes a  element  
doesn't mean that every browser has to have a built in dictionary for  
storing all the definitions people collect on the web, but the  
element is there for those people who want to use it. Browsers  
*could* do something useful with  if they liked, but none so far  
seem to have done so.


--
Toby A Inkster

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Ian Hickson

On Fri, 29 Aug 2008, Elliotte Harold wrote:
> 
> I fully expect to be revisiting this whole mess in 5-10 years to come up 
> with a real spec, after we've seen which of the experiments succeeded 
> and which failed. Then again maybe we'll just decide that specs don't 
> matter, and live with whatever browser vendors choose to implement.

That's actually exactly the process we are following. Spec things that we 
can justify and can get experimental implementations for, try to get more 
implementations, remove stuff that fails in the market place. That's one 
of the reasons the timetable for HTML5 has the work planned to continue 
until at least 2022.

For details see the FAQ:

   http://wiki.whatwg.org/wiki/FAQ

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

Re: [whatwg] RDFa uses CURIEs, not QNames

2008-08-29 Thread Elliotte Rusty Harold


Ben Adida wrote:


We're not dealing with an existing technology that is going to be made
somehow incompatible because of CURIE support. None of the existing HTML
tools will have to change (they already ignore attributes they don't
know, given that, e.g., a number of JavaScript libraries use their own
attributes). None of the HTML parsers will have to change. None of the
other specifications will have to change one iota.

The changes we're proposing are entirely self-contained.



Sadly, they aren't, though not in the way you mean.

The specific problem I refer to is that the string foo:localName has no 
defined namespace absent an outer context. Leaving aside all the other 
problems with namespaces (and they are legion) that was a mistake. And 
CURIEs most definitely appear to be repeating that mistake.


Unlike namespaces, though, CURIEs are unlikely to convince maintainers 
of DOM/SAX/JDOM/XPath/XQuery/etc. to add special support for their 
indirection. This is going to make them even harder for developers to 
use. :-(


--
Elliotte Rusty Harold
[EMAIL PROTECTED]

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Henri Sivonen


On Aug 29, 2008, at 11:11, Julian Reschke wrote:


Henri Sivonen wrote:

I don't believe that is the case.
If I've understood history correctly, introducing Namespaces into  
XML was primarily a requirement stipulated by the RDF community.  
XML got


Pointer, please?


http://lists.w3.org/Archives/Public/semantic-web/2007Dec/0116.html


...
I like the GRDDL approach of seeing RDF there by looking at non-RDF  
things just right--with the modification that the person who wants  
to look just right is the one supplying the transform.

...


I like GRDDL, too, but it has problems with respect to scaling  
similar to microformats. Things will get complicated when you want  
to combine statements from different vocabularies on the same page.


The completely prefixless microformat naming approach isn't good when  
different microformats overlap and common words have been allocated  
badly. It works if you can decide that all classes that are on  
descendants of a class identifying a format root belong to that format  
(i.e. the subtree root is effectively the prefix).


If vocabularies are designed to overlap, instead of having "title" it  
would be better to have "hcard-title". Still no need for all the full  
URI stuff in HTML. That could live in the GRDDL transform.



...

Browsers don't
need to do anything (except make the attributes available in the  
DOM,

which they would probably do anyways.)
I'm getting mixed signals about the extent to which RDFa in  
envisioned to be browser-sensitive. Weren't browsers supposed to do  
cool stuff with it according to some emails in this thread?

...


Browsers are not "supposed" to do with RDFa anymore than, for  
instance, with microformats.



I've seen Mozilla Ubiquity referred to several times in this thread-- 
presumably with the implication that something like Mozilla Ubiquity  
should be RDFa-based. That would be more than just ignoring  
attributes. (As far as I can tell, Ubiquity is not RDFa-based.)


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] RDFa Features

Henri Sivonen wrote:
> I always copy & paste, too. That's my point. Namespace waste my time
> almost every day.

If all you did was produce content and no one ever consumed it, indeed
namespaces would be a waste of time.

But the time you're spending is not wasted if it helps consumers make
more sense of the data as time goes on.

-Ben

Re: [whatwg] RDFa statement consistency

Kristof Zelechovski wrote:
> The goal of the specification is to provide a set of rules that conformant
> user agents must obey out of the box, without any extensions.  Features that
> are supposed to be ignored do not make good candidates for including in the
> specification, except as extensions to HTML that are explicitly supported.

We would be happy if RDFa were an extension to HTML5.

-Ben

Re: [whatwg] RDFa statement consistency

The goal of the specification is to provide a set of rules that conformant
user agents must obey out of the box, without any extensions.  Features that
are supposed to be ignored do not make good candidates for including in the
specification, except as extensions to HTML that are explicitly supported.
Chris

-Original Message-
From: Ben Adida [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2008 6:05 PM
To: Henri Sivonen
Cc: whatwg@lists.whatwg.org; Kristof Zelechovski; 'Manu Sporny'
Subject: Re: [whatwg] RDFa statement consistency

> I'm getting mixed signals about the extent to which RDFa in envisioned
> to be browser-sensitive. Weren't browsers supposed to do cool stuff with
> it according to some emails in this thread?

Loose coupling. Browsers can do nothing or lots with RDFa, up to them.
But you don't have to mandate anything, certainly not any rendering
behavior.

No mixed message, just flexibility in what user agents choose to
implement. In fact, I'd rather they implement nothing and let extensions
like Ubiquity do the work.

-Ben

Re: [whatwg] RDFa statement consistency

Henri Sivonen wrote:
> Now we have people from the RDF community asking for CURIEs in HTML.

No. I'm not "from the RDF community." I am from Creative Commons. I
represent Creative Commons at the W3C. I have done no research or active
work on RDF, only on integrating RDF in HTML, because RDF was clearly
the best metadata model for our needs.

I am a member of the *Web* community. I believe URLs are useful. The
overhead you mention is easily optimized by caching common namespaces,
all the while maintaining a *Web* architecture, where you don't hand
over power to a central authority, you allow many to develop their own
vocabularies, and you let a thousand flowers bloom.

I understand that "RDF" is a four-letter word in some circles. But I
deal with the realities of what's needed for the kinds of applications
that we envision at Creative Commons, so it's important for me to get
over the exaggerated (and unprofessional) badmouthing of RDF and see
what it offers.

The SemWeb folks will tell you that I criticize large parts of RDF all
the time. I think many mistakes were made. But there are also many solid
design principles, especially if you believe in the Web.

> Even if the experiment didn't work out, the damage would already have
> been done, and the HTML community would be stuck with supporting CURIEs.

No. You don't have to support them at all. You can say that "browsers
are free to ignore these attributes. If browsers or other user agents
want to parse them, they should use the RDFa specification."

The *rest* of your HTML is completely unaffected. This is quite
different from the XML experience you describe, where you have to be
namespace-aware to start parsing anything. So, not a fair comparison by
any stretch.

> Or even if we were able to negotiate CURIEs away and settle on full
> URIs, the HTML community would be stuck with unwieldy identifiers (just
> consider how much things would suck if HTML element names had to be
> written as URIs).

We agree, writing out full URIs often sucks, which is why we limit that
with prefixes. But we never claimed we needed to do so with element
*names*, that's a strawman argument.

> It's really not nice to impose the RDF tax onto the HTML community.

It's not the RDF tax. It's the Web tax. It's building an architecture
that supports distributed innovation, that says your URL is not
inherently more powerful than mine.

You want monolithic, top-down, one solution-fits-all. I want the Web.

> Back in the Atom WG, there was also the issue that some RDF proponents
> wanted to make Atom RDF. Instead of making all Atom consumers deal with
> RDF, we specced a way for mapping Atom rel keywords onto URIs, so people
> who want to see the world as URIs, can see it as URIs but the rest of us
> don't have to.

Doesn't Atom have namespaces for all of its extensions, i.e. gdata? Why
aren't you complaining there? In fact, the funny thing is that Atom is
effectively RDF, because it's XML that doesn't have a very strict
schema, since you can extend every which way you like, add extra
namespaces, etc... and pretty soon it looks like RDF/XML, only it's not
called that.

I suspect you're more afraid of the acronym "RDF" than you are of the
actual technology.

> I like the GRDDL approach of seeing RDF there by looking at non-RDF
> things just right--with the modification that the person who wants to
> look just right is the one supplying the transform.

GRDDL is great, but in the HTML case it has some significant downsides.
It doesn't let you do the important Ubiquity-like use case: where you
point to an area of the screen and you get exactly *that* structured data.

> The point of
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016021.html
> was to try to come up with a scheme that allows people who want to see
> HTML as RDF to see it that way, but in doing so making them pay the RDF
> tax so that those who don't need or want to see HTML as RDF do not need
> to pay the RDF tax.

This entire line of reasoning around the "RDF tax" is, in my opinion,
bogus. There is no significant RDF-specific tax in the proposal we're
making. The question is whether you believe in a Web-like architecture,
or whether you want all parsers to know all sorts of pre-defined kludges
ahead of time. Monolithic vs the Web.

Is it a bit slower to do things with a Web-like architecture?
Absolutely. That's the price we pay for flexibility, a price we already
accept by getting on the web in the first place, e.g. visiting sites
that include JavaScript from other servers which then slow down the
rendering of the page, etc

> I'm getting mixed signals about the extent to which RDFa in envisioned
> to be browser-sensitive. Weren't browsers supposed to do cool stuff with
> it according to some emails in this thread?

Loose coupling. Browsers can do nothing or lots with RDFa, up to them.
But you don't have to mandate anything, certainly not any rendering
behavior.

No mixed message, just flexibility in wh

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Julian Reschke


Elliotte Harold wrote:

Julian Reschke wrote:


Parts of the community are totally happy with them.


You have got to be kidding me. I can't think of anyone who is totally 
happy with namespaces in XML. I can't even think of anybody who is happy 
with. The best I think anyone claims is tolerance. Even full-time XML 
geeks like me have a real distaste for namespaces, and admit the design 
is seriously flawed.


Seriously, can anyone here stand up and say, "I really like namespaces 
in XML."? If so, can you please explain why?


I do.

They solve the problem they are supposed to solve. I've been taking 
advantage of them in many many projects over the last few years, and it 
really all works as expected.


I admit that there are some aspects that suck; the main one being the 
primitive support in DOM, and the fact that it took years until 
serializers did work as expected (without the programmer having to 
explicitly deal with xmlns attributes).


Of course it's totally cool nowadays to diss XML namespaces -- it would 
be interesting to see what other design and syntax would have worked 
better, and which decisions about the syntax may be wrong in 
retrospective. But then it's also cool to prefer JSON or tag soup over XML.


But that would be a discussion for xml-dev.

BR, Julian

Re: [whatwg] RDFa uses CURIEs, not QNames

Elliotte Harold wrote:
> In my experience, that level of indirection is a disaster. It is the
> single most problematic part of XML as practiced. It destroyed XPointer.
>   It takes what should be a simple, atomic value and makes it context
> dependent. 

That's not the same thing at all.

XML Namespaces may have been added in a way that didn't play well with
the dozens of other pre-existing XML technologies. That doesn't mean the
*concept* of namespacing and indirection are wrong.

> I'm surprised you want to reinvent that particular mistake.

Maybe because you're looking at the wrong context.

We're not dealing with an existing technology that is going to be made
somehow incompatible because of CURIE support. None of the existing HTML
tools will have to change (they already ignore attributes they don't
know, given that, e.g., a number of JavaScript libraries use their own
attributes). None of the HTML parsers will have to change. None of the
other specifications will have to change one iota.

The changes we're proposing are entirely self-contained.

So while the way in which namespaces were introduced in XML may have
been a mistake, I don't give much credit to the argument that
namespacing and indirection *in general* are mistakes. Quite the
contrary, they are crucial software design principles.

I'm surprised you've over-generalized from your bad XML experience.

-Ben

Re: [whatwg] RDFa statement consistency


Kristof Zelechovski wrote:


Do you think that HTML5 should allow arbitrary experimentation under the
banner "Let us just do it and we shall see?"  


I don't think HTML 5 should allow arbitrary experimentation.

That doesn't change the fact that the HTML 5 spec is full of arbitrary 
experimentation, which is one of the reasons I think this whole effort 
has gone badly off the rails and will fail.


I fully expect to be revisiting this whole mess in 5-10 years to come up 
with a real spec, after we've seen which of the experiments succeeded 
and which failed. Then again maybe we'll just decide that specs don't 
matter, and live with whatever browser vendors choose to implement.


Maybe that's OK. That's pretty much how the Web has worked for close to 
20 years now, and it seems to be muddling along. Maybe no HTML spec has 
ever really been anything but an experiment anyway.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Re: [whatwg] RDFa statement consistency


Julian Reschke wrote:


Parts of the community are totally happy with them.


You have got to be kidding me. I can't think of anyone who is totally 
happy with namespaces in XML. I can't even think of anybody who is happy 
with. The best I think anyone claims is tolerance. Even full-time XML 
geeks like me have a real distaste for namespaces, and admit the design 
is seriously flawed.


Seriously, can anyone here stand up and say, "I really like namespaces 
in XML."? If so, can you please explain why?


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Re: [whatwg] RDFa statement consistency


Henri Sivonen wrote:

I like the GRDDL approach of seeing RDF there by looking at non-RDF 
things just right--with the modification that the person who wants to 
look just right is the one supplying the transform.


There's a really simple algorithm for deciding whether to introduce a 
feature, tag, or datum that RDF folks want. Pretend you've never heard 
of RDF, OWL, or the Semantic Web. Eliminate all arguments in favor that 
reference RDF, OWL, or the Semantic Web. Then ask, "Does the addition 
still make sense?" If so, add it, If not, leave it out.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Re: [whatwg] RDFa uses CURIEs, not QNames


Ben Adida wrote:


It's important to note that, in our experience and in our design, the
level of indirection is a feature, not a bug. One rarely uses a
vocabulary for just one property.


In my experience, that level of indirection is a disaster. It is the 
single most problematic part of XML as practiced. It destroyed XPointer. 
  It takes what should be a simple, atomic value and makes it context 
dependent. I'm surprised you want to reinvent that particular mistake.


--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Refactoring HTML Just Published!
http://www.amazon.com/exec/obidos/ISBN=0321503635/ref=nosim/cafeaulaitA

Re: [whatwg] RDFa uses CURIEs, not QNames

2008-08-29 Thread Thomas Broyer

On Fri, Aug 29, 2008 at 4:57 PM, Ben Adidawrote:
> Anne van Kesteren wrote:
>> As far as I can tell they both have the same (subset of) problems. They
>> create a level of indirection and require keeping namespace prefix
>> declarations around.
>
> It's important to note that, in our experience and in our design, the
> level of indirection is a feature, not a bug. One rarely uses a
> vocabulary for just one property.

The bug is in that attribute values are opaque strings unless told
otherwise (e.g. through a schema), so most processors won't know that
a particular attribute's value is a CURIE and that they need to copy
the namespace declaration and/or keep the prefix the same; and people
copy/pasting things will have to know it's a CURIE and they have to
find and copy/paste the namespace declaration too (and know where to
paste it).

The problem with QNames is not QNames by themselves (except for their
key+value nature, but that's another story), it's their use in
attribute values (e.g. in XSLT). QNames should probably have defined a
"string serialization" (such as the "James Clark's notation":
{namespace-uri}local-name) to be used by other specifications, or at
least the first major spec using QNames in attribute values (wasn't it
XSLT?) should have defined it (expecting others to follow the same
rule).

(note that I talked about attribute values, but the same is true for
element's text value)
-- 
Thomas Broyer

Re: [whatwg] RDFa Features

Kristof Zelechovski wrote:
> "Does not use QNames" is not an advantage any more than "does not require
> the user to be a USA citizen".  So you could have listed that as well.
> I would like to append the following to the disadvantages:
> The interface A[property] is very misleading.  You read it as "The property
> of this anchor is cc:creator".  That does not make any sense (an anchor has
> several properties and cc:creator is not one of them) and it does not
> reflect what you want to say, which is "this anchor represents a property
> named cc:creator of its enclosing element".  I am not sure how to fix this;
> "isProperty" would be better but still not very good.

Let's make sure not to discuss everything at once.

The first point is that embedded metadata with RDFa has clear use cases
and does not lead to any more logical issues than normal human-readble
web pages. I don't know if you agree with that yet, but we think we've
made some solid points to support this argument.

The second point is: what should the names of the actual attributes be?
Well, we can argue about that till the cows come home. No matter what
you choose, a lot of people will be unhappy because they "read" the HTML
in different ways. We think we've picked attribute names that are rather
harmless and that are "close enough" to what we mean. And we had an open
discussion about it for 2 years. At some point, you have to declare that
an issue like this one is "good enough."

Let's try keep those two points of discussions separate.

-Ben

Re: [whatwg] RDFa uses CURIEs, not QNames

Anne van Kesteren wrote:
> As far as I can tell they both have the same (subset of) problems. They
> create a level of indirection and require keeping namespace prefix
> declarations around.

It's important to note that, in our experience and in our design, the
level of indirection is a feature, not a bug. One rarely uses a
vocabulary for just one property.

-Ben

Re: [whatwg] RDFa Features

James Graham wrote:
> Given the problems with using DNS as your registry noted above and the
> fact that the recommended solution to this problem is to use a small
> number of registries built atop DNS that promise greater longevity than
> DNS registrations can ensure, it doesn't seem unreasonable to have a
> single permanent registry that provides (at least for HTML 5) a
> canonical prefix:url mapping.

I don't think that argument follows quite the way you frame it. Even if
the recommendation is to use long-lasting registries, you can still
choose the registry you want, build your own, etc... Meanwhile, the
centrally registered prefixes are, well, *centrally* controlled, which
is a very different architectural choice, and, where data is concerned,
not as web-like as one really wants.

> So instead of the use of cc:foo requiring
> a deceleration of cc elsewhere in the document, cc would be declared at,
> say, cc.rdfa.net and would be a globally unique prefix from the point of
> view of the author. People not wanting to bother registering would just
> have to use full URLs everywhere. This would seem to provide the "follow
> your nose" principle you desire, remove several of the objections to
> URL-based namespaces, make authoring for the common case of well known
> vocabularies easier, and have only mildly different distributedness
> characteristics to the current recommended practice.

That said, I don't think this is a bad idea at all.

In defining RDFa, we said that various host languages (HTML5, XHTML1.1,
XHTML2, ...) may choose to include some built-in additional definitions,
e.g. new reserved keywords in @rel.

I am certainly open to considering a mechanism for pre-defined prefixes
in HTML5+RDFa, as long as they are machine-discoverable by
follow-your-nose (likely via the HTML5 spec doc), and as long as those
prefixes can be overridden in a given document and new prefixes can be
defined at will.

And I appreciate this suggestion, which definitely moves the discussion
forward!

-Ben

Re: [whatwg] RDFa Features

2008-08-29 Thread Tab Atkins Jr.

Manu Sporny wrote:

> Tab Atkins Jr. wrote:
>>
>>
>>> On Thu, Aug 28, 2008 at 4:42 PM, Kristof Zelechovski
>>> <[EMAIL PROTECTED] > wrote:
>>>
>>>Ian's question was about what happens when it goes down forever, or
>>> gets
>>>taken over, intercepted, squatted, spoofed or redirected because of a
>>>malicious DNS.  I should have known better how to ask it.  The
>>>browser cache cannot handle these cases.
>>>
>>> Consider the question to be asked by me as well.  A host of a popular
>>> format forgets to maintain its registration and gets squatted by a
>>> malicious person. They pick up another url to host their schema on, but
>>> legacy pages are still pointing to the old url and now may have poisoned
>>> semantics.  Do we have a recourse?
>>>
>>>
>>
>> The way we deal with this today is by using a Persistent URL (aka: URL
>> re-direction service) such as purl.org[1] or xmlns.com[2]. We recommend
>> that all authors use such a service for their vocabularies. This is how
>> the Media, Audio, Video and Commerce RDF vocabularies are hosted.
>
>
Thanks, Manu.  That does help address my concern.  However:

On Fri, Aug 29, 2008 at 3:34 AM, James Graham <[EMAIL PROTECTED]> wrote:

> Given the problems with using DNS as your registry noted above and the fact
> that the recommended solution to this problem is to use a small number of
> registries built atop DNS that promise greater longevity than DNS
> registrations can ensure, it doesn't seem unreasonable to have a single
> permanent registry that provides (at least for HTML 5) a canonical
> prefix:url mapping. So instead of the use of cc:foo requiring a deceleration
> of cc elsewhere in the document, cc would be declared at, say, cc.rdfa.netand 
> would be a globally unique prefix from the point of view of the author.
> People not wanting to bother registering would just have to use full URLs
> everywhere. This would seem to provide the "follow your nose" principle you
> desire, remove several of the objections to URL-based namespaces, make
> authoring for the common case of well known vocabularies easier, and have
> only mildly different distributedness characteristics to the current
> recommended practice.


I seem to always be a few hours behind in this thread...   Rather than
rewrite what Graham said, I'll just say that I echo his suggestion.

~TJ

Re: [whatwg] RDFa uses CURIEs, not QNames

2008-08-29 Thread Anne van Kesteren

On Fri, 29 Aug 2008 07:08:37 +0200, Manu Sporny  
<[EMAIL PROTECTED]> wrote:

Anne van Kesteren wrote:

The idea and premise of RDF is sort of attractive (people being able to
do their own thing, unified data model, etc), though I agree with others
that the complexity (lengthy URIs, ***qname***/curie cruft) is an issue.


We do not use QName's in RDFa - there is not QName/CURIE cruft! We went
to great lengths to avoid QNames, please take the time to understand why
(it's because of the cruft that you complain about):


As far as I can tell they both have the same (subset of) problems. They  
create a level of indirection and require keeping namespace prefix  
declarations around.



--
Anne van Kesteren

Re: [whatwg] RDFa Features

2008-08-29 Thread James Graham


Manu Sporny wrote:

Tab Atkins Jr. wrote:
  

On Thu, Aug 28, 2008 at 4:42 PM, Kristof Zelechovski
<[EMAIL PROTECTED] > wrote:

Ian's question was about what happens when it goes down forever, or gets
taken over, intercepted, squatted, spoofed or redirected because of a
malicious DNS.  I should have known better how to ask it.  The
browser cache cannot handle these cases.

Consider the question to be asked by me as well.  A host of a popular
format forgets to maintain its registration and gets squatted by a
malicious person. They pick up another url to host their schema on, but
legacy pages are still pointing to the old url and now may have poisoned
semantics.  Do we have a recourse?



The way we deal with this today is by using a Persistent URL (aka: URL
re-direction service) such as purl.org[1] or xmlns.com[2]. We recommend
that all authors use such a service for their vocabularies. This is how
the Media, Audio, Video and Commerce RDF vocabularies are hosted.
  
Given the problems with using DNS as your registry noted above and the 
fact that the recommended solution to this problem is to use a small 
number of registries built atop DNS that promise greater longevity than 
DNS registrations can ensure, it doesn't seem unreasonable to have a 
single permanent registry that provides (at least for HTML 5) a 
canonical prefix:url mapping. So instead of the use of cc:foo requiring 
a deceleration of cc elsewhere in the document, cc would be declared at, 
say, cc.rdfa.net and would be a globally unique prefix from the point of 
view of the author. People not wanting to bother registering would just 
have to use full URLs everywhere. This would seem to provide the "follow 
your nose" principle you desire, remove several of the objections to 
URL-based namespaces, make authoring for the common case of well known 
vocabularies easier, and have only mildly different distributedness 
characteristics to the current recommended practice.

Re: [whatwg] RDFa Features

"Does not use QNames" is not an advantage any more than "does not require
the user to be a USA citizen".  So you could have listed that as well.
I would like to append the following to the disadvantages:
The interface A[property] is very misleading.  You read it as "The property
of this anchor is cc:creator".  That does not make any sense (an anchor has
several properties and cc:creator is not one of them) and it does not
reflect what you want to say, which is "this anchor represents a property
named cc:creator of its enclosing element".  I am not sure how to fix this;
"isProperty" would be better but still not very good.
Chris

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Manu Sporny
Sent: Friday, August 29, 2008 7:33 AM
To: whatwg@lists.whatwg.org
Subject: Re: [whatwg] RDFa Features

Kristof Zelechovski wrote:
> While Google owns the Web, it is not the core of the Web.  If Google goes
> down, Google users cannot use Google any more.  Sure, there are quite a
few
> of them; but Google is a big fish accordingly.
> On the other hand, if Verizon or InterNIC goes down, we have a blackout,
> possibly with street riots and people plundering stores.  That shows
Verizon
> is an authority, Google is not, although, in general, Google is more
useful.
> I believe in the general sanity in the architecture of the Web.  I keep
> asking these questions because I would like it to stay.

Kristof - you will have to be more precise. Could you please outline (in
short form bulleted list), every specific issue that you have with RDFa.
 A parallel short-form bulleted list of all RDFa features that you enjoy
would also be welcome. I believe that this thread has been going long
enough for you to formulate an educated opinion about what you do like
and what you don't like about RDFa. Getting such a list together will
also help us address your grievances better.

Here's an example of what I'd like to see:

RDFa Pros:
- Allows semantic metadata markup in HTML family languages.
- Does not use QNames

RDFa Cons:
- Mixes semantics with HTML structure
- Uses CURIEs to specify prefixes
- Does not work like CSS and does not re-use @class

and so on...

If any of you that have been involved in all of these discussions can
weight in with a list like that it would be very helpful. I can put
together a set of issues that the HTML5 community is concerned about and
we can start discussing them in the W3C RDFa Task Force.

-- manu

-- 
Manu Sporny
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.0 Website Launches
http://blog.digitalbazaar.com/2008/07/03/bitmunk-3-website-launches

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Julian Reschke


Henri Sivonen wrote:

I don't believe that is the case.

If I've understood history correctly, introducing Namespaces into XML 
was primarily a requirement stipulated by the RDF community. XML got 


Pointer, please?

Namespaces, but then at least notable parts of the RDF community figured 
that they didn't like RDF/XML all that much and started doing N-triples, 
N3 and Turtle. The damage was already done, and now the XML community is 
stuck with Namespaces in XML.


Parts of the community are totally happy with them.


...
I like the GRDDL approach of seeing RDF there by looking at non-RDF 
things just right--with the modification that the person who wants to 
look just right is the one supplying the transform.

...


I like GRDDL, too, but it has problems with respect to scaling similar 
to microformats. Things will get complicated when you want to combine 
statements from different vocabularies on the same page.



 ...

Browsers don't
need to do anything (except make the attributes available in the DOM,
which they would probably do anyways.)


I'm getting mixed signals about the extent to which RDFa in envisioned 
to be browser-sensitive. Weren't browsers supposed to do cool stuff with 
it according to some emails in this thread?

...


Browsers are not "supposed" to do with RDFa anymore than, for instance, 
with microformats.


BR, Julian

Re: [whatwg] RDFa statement consistency

2008-08-29 Thread Henri Sivonen


On Aug 29, 2008, at 00:29, Ben Adida wrote:


Plus, consider the risk to HTML5: nothing.


I don't believe that is the case.

If I've understood history correctly, introducing Namespaces into XML  
was primarily a requirement stipulated by the RDF community. XML got  
Namespaces, but then at least notable parts of the RDF community  
figured that they didn't like RDF/XML all that much and started doing  
N-triples, N3 and Turtle. The damage was already done, and now the XML  
community is stuck with Namespaces in XML.


I write software that processes XML, so every time I have to look up a  
namespace URI, I'm effectively paying a spill-over RDF tax. When my  
software runs slower because it has to compare two strings instead of  
one, the users of my software are paying a spill-over RDF tax. I  
seriously don't like paying the spill-over RDF tax in the form of  
Namespaces.


Now we have people from the RDF community asking for CURIEs in HTML.  
Even if the experiment didn't work out, the damage would already have  
been done, and the HTML community would be stuck with supporting  
CURIEs. Or even if we were able to negotiate CURIEs away and settle on  
full URIs, the HTML community would be stuck with unwieldy identifiers  
(just consider how much things would suck if HTML element names had to  
be written as URIs).


It's really not nice to impose the RDF tax onto the HTML community.

Back in the Atom WG, there was also the issue that some RDF proponents  
wanted to make Atom RDF. Instead of making all Atom consumers deal  
with RDF, we specced a way for mapping Atom rel keywords onto URIs, so  
people who want to see the world as URIs, can see it as URIs but the  
rest of us don't have to.


I like the GRDDL approach of seeing RDF there by looking at non-RDF  
things just right--with the modification that the person who wants to  
look just right is the one supplying the transform.


The point of
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-August/016021.html
was to try to come up with a scheme that allows people who want to see  
HTML as RDF to see it that way, but in doing so making them pay the  
RDF tax so that those who don't need or want to see HTML as RDF do not  
need to pay the RDF tax.



Browsers don't
need to do anything (except make the attributes available in the DOM,
which they would probably do anyways.)


I'm getting mixed signals about the extent to which RDFa in envisioned  
to be browser-sensitive. Weren't browsers supposed to do cool stuff  
with it according to some emails in this thread?


--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/

Re: [whatwg] RDFa statement consistency