subject:"\[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=104STORY=/www/story/9-8-97/312711EDATE=

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

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

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 Anne van Kesteren

On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers  
shell...@burningbird.net 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  
self-closed / 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
http://annevankesteren.nl/
http://www.opera.com/

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 
shell...@burningbird.net 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 self-closed / 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 17:15:34 +0100, Shelley Powers  
shell...@burningbird.net 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
http://annevankesteren.nl/
http://www.opera.com/

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

2009-01-18 Thread Henri Sivonen


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


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

2009-01-18 Thread Sam Ruby

On Sun, Jan 18, 2009 at 1:34 PM, Henri Sivonen hsivo...@iki.fi 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

2009-01-18 Thread Henri Sivonen


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


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

2009-01-18 Thread Eduard Pascual

On Sun, Jan 18, 2009 at 3:56 PM, Anne van Kesteren ann...@opera.com wrote:
 On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers
 shell...@burningbird.net 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
 self-closed / and then WordPress somehow messed up in an attempt to fix
 it. I don't think anyone tries to make you shut up.

Ouch! Thanks Anne for the screenshot, otherwise I wouldn't have known
that it was my comment the one causing the issue.
My apologies Shelley for that incident. I assure you that it was not
intentional: it was a quite long post, I used some markup with the
intention of making it more readable (like italizing the quotes), and
by the end I messed things up. Thanks to the preview page I noticed
some issues, like that I had to escape the sarcasm.../sarcasm
for it to display (I'm too used to BBCode, which leaves unrecognized
markup as is), but I didn't catch the self-closed / one (nor the
preview page did: it showed up without issues).

On Sun, Jan 18, 2009 at 4:15 PM, Shelley Powers
shell...@burningbird.net wrote:
 You're not seeing all of the markup that caused problems, Anne. The
 intention was to crash the post.
I don't really know how much did I mess up the markup on that post;
and I only managed to fix the issues that I spotted from the preview
page, so I wouldn't be surprised if there were more issues. Once more,
I would like to clarify that this was not intentional; but, given the
tension arising again from this debate, I can understand your
reaction.

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

2009-01-18 Thread Nils Dagsson Moskopp

Am Sonntag, den 18.01.2009, 21:30 + schrieb Eduard Pascual:
 On Sun, Jan 18, 2009 at 3:56 PM, Anne van Kesteren ann...@opera.com
 wrote:
  On Sun, 18 Jan 2009 16:22:40 +0100, Shelley Powers
  shell...@burningbird.net wrote:
  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
  self-closed / and then WordPress somehow messed up in an attempt to fix
  it. I don't think anyone tries to make you shut up.
 
 Ouch! Thanks Anne for the screenshot, otherwise I wouldn't have known
 that it was my comment the one causing the issue.
Which is why I disabled Wordpress autofixing. My suggestion would be: If
it doesn't validate, either reject it or escape f*cking everything.

(No, please don't point out that I'm using Wordpress as well and
vulnerable to similar things.)

 On Sun, Jan 18, 2009 at 4:15 PM, Shelley Powers
 shell...@burningbird.net wrote:
  You're not seeing all of the markup that caused problems, Anne. The
  intention was to crash the post.
 I don't really know how much did I mess up the markup on that post;
 and I only managed to fix the issues that I spotted from the preview
 page, so I wouldn't be surprised if there were more issues. Once more,
 I would like to clarify that this was not intentional; but, given the
 tension arising again from this debate, I can understand your
 reaction.
Apparently just bad Software not validating input. In the end I'm unsure
what people are unruly about - anyone can explain what is the big deal ?

Well-formed cheers !
-- 
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net

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

2009-01-18 Thread Toby A Inkster


Dan Brickley wrote:

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


Actually, most RDFa parsers will break if full URIs are used in RDFa  
attributes: in RDFa all CURIEs need a prefix which is a string of  
zero or more alphanumeric characters, dashes and hyphens followed by  
a colon (and yes, the empty string is allowed - but it is permanently  
bound to http://www.w3.org/1999/xhtml/vocab#). The proposed  
recommendation (IIRC, that's the current status) for CURIEs *does*  
actually allow for unprefixed CURIES, but RDFa enforces extra  
conditions. (As it was published before the CURIE spec, which is a  
spin-off of RDFa.)


A suggestion I've heard for using full URIs is:

html xmlns:http=http:
  title property=http://purl.org/dc/terms/title;Foo/title
/html

Which should theoretically work according to the reference algorithm  
in the RDFa syntax document, however it does (I believe) break the  
XML Namespaces spec. (Though that wouldn't be a problem if an  
alternative, non-xmlns, syntax were adopted for CURIE prefix  
binding.) It wouldn't surprise me if a few RDFa parsers had issues  
with this caused by the front-end XML parser they use.


So RDFa, as it is currently defined, does need a CURIE binding  
mechanism. XML namespaces are used for XHTML+RDFa 1.0, but given that  
namespaces don't work in HTML, an alternative mechanism for defining  
them is expected, and for consistency would probably be allowed in  
XHTML too - albeit in a future version of XHTML+RDFa, as 1.0 is  
already finalised. (I don't speak for the RDFa task force as I am not  
a member, but I would be surprised if many of them disagreed with me  
strongly on this.)


Back to when I said most RDFa parsers will break if full URIs are  
used in RDFa attributes. The Perl library RDF::RDFa::Parser doesn't,  
so if you want to do any testing with full URIs, it can be found on  
CPAN. Full URIs are a pain to type though - I certainly prefer using  
CURIEs.


--
Toby A Inkster
mailto:m...@tobyinkster.co.uk
http://tobyinkster.co.uk

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, Shelley Powers wrote:
  
  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.

I'm certainly sad that this is the impression I have given. I'd like to 
clarify for everyone's sake that this mailing list is definitely open to 
any proposals, any opinions, any disagreement. The only thing I ask is 
that people use rational debate, back up their opinions with logical 
arguments, present research to justify their claims, and derive proposals 
from user needs.


 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.

For the record, I am as open to us including a feature like RDFa as I am 
to us including a feature like MathML, SVG, or indeed anything else. While 
I may present a devil's advocate position to stimulate critical 
consideration of proposals, this does not mean that my mind is made up. If 
my mind was made up, I wouldn't be asking for use cases, and I wouldn't 
be planning to investigate the issue further in April.


 I am not paid by Google, or Mozilla, or IBM to continue throwing away my 
 time, arguing for naught.

It may be worth pointing out that, many of our most active participants 
are volunteers, not paid by anyone to participate. Indeed I myself spent 
many years contributing to the standards community while unemployed or 
while a student. I am sorry you feel that you need to be compensated for 
your participation in the standards community, and wish you the best of 
luck in finding a suitable employer.

As far as Google goes, we have no corporate opinion either way on the 
topic of RDFa in HTML5. We do, however, encourage the continued practice 
of basing decisions on data rather than hopes.

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

[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 
mechanism, and SVG is a natural for

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
shell...@burningbird.net 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

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
shell...@burningbird.net  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


Dan Brickley wrote:

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

On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
shell...@burningbird.net  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

On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote:
 On 17/1/09 19:27, Sam Ruby wrote:

 On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
 shell...@burningbird.net  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

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


Sam Ruby wrote:

On Sat, Jan 17, 2009 at 1:33 PM, Dan Brickley dan...@danbri.org wrote:
  

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


On Sat, Jan 17, 2009 at 11:55 AM, Shelley Powers
shell...@burningbird.net  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


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


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

On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
shell...@burningbird.net 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


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


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


Sam Ruby wrote:

On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
shell...@burningbird.net 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

On Sat, Jan 17, 2009 at 3:51 PM, Shelley Powers
shell...@burningbird.net wrote:
 Sam Ruby wrote:

 On Sat, Jan 17, 2009 at 2:38 PM, Shelley Powers
 shell...@burningbird.net 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

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=defaultmodule=allbranch=HEADbranchtype=matchdir=mozilla%2Frdffile=filetype=matchwho=whotype=matchsortby=Datehours=2date=explicitmindate=1998-01-01maxdate=1999-01-01cvsroot=%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 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


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





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