See also: IRC log, previous 2009-01-08
ACTION: [CONTINUES] fix the .htaccess for the XHTML namespace [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action01]
ACTION: [CONTINUES] Manu to create TC to test @resource="[]" does not set object based on TC 123. [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action14]
ACTION: [CONTINUES] Manu to look at http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Dec/0037.html [recorded in http://www.w3.org/2009/01/08-rdfa-minutes.html#action15]
Manu: first part of the comment was a
misunderstanding of the test
... I explained how we do negative results in the test suite
... second part of the comment came from use of old saxon parser
... there is a choice of which RFC to follow and they result in different
xpath URIs
... it's a strange issue with XSLT-based implementations
Shane: does the XSLT spec reference the wrong thing?
Manu: no, it gives a choice of RFCs
... I need to check the XSLT spec more closely
... Sergey said he'd talked with the implementor and there isn't yet an
updated implementation that he could use
<msporny> Re: Problematic test cases in the RDFa test suite [Manu2009-01-22]
ACTION: [PENDING] Ben to add public-rdfa examples to wiki and think of slightly improved top-level organization [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action11]
ACTION: [PENDING] Ben to put up information on "how to write RDFa" with screencast possibly and instructions on bookmarklet. [recorded in http://www.w3.org/2008/11/06-rdfa-minutes.html#action12]
ACTION: [PENDING] Jeremy to demonstrate GRDDL with XHTML/RDFa once the NS URI is set up. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action03]
ACTION: [DONE] Manu talk with Jamie McCarthy about an AskSlashdot piece [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action04]
Manu: I've written to Jamie
... he hasn't responded, so I propose to close it for now
ACTION: [PENDING] Manu to write summary for Semantic Web Use Cases for Ivan. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action09]
ACTION: [WITHDRAWN] Manu write the perl code for Slashdot. [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action11]
Manu: I've spent some time on this and it looks
like a lot of work
... Slashdot doesn't generate clean HTML4
Manu: I don't want to have to fix all their
templates; it will be a large patch that they may not accept
... I won't have the time to generate this massive patch
... would need more buy-in from Slashdot
... I think I've done as much as I can
Shane: Slashdot is an interesting community but
it doesn't really affect the broader community
... Drupal on the other hand would affect a broader community and makes more
sense for our attention
Manu: Wordpress would be another likely candidate
ACTION: [PENDING] Mark create base wizard suitable for cloning [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action12]
ACTION: [PENDING] Mark to review reasoning on setting explicit about="" on HEAD and BODY [recorded in http://www.w3.org/2008/12/18-rdfa-irc]
ACTION: [PENDING] Mark to send Ben ubiquity related wizard stuff [recorded in http://www.w3.org/2008/11/20-rdfa-minutes.html#action11]
ACTION: [PENDING] Mark write foaf examples for wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action13]
ACTION: [PENDING] Michael to create 'RDFa for uF users' on RDFa Wiki [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action14]
ACTION: [PENDING] Ralph think about RSS+RDFa [recorded in http://www.w3.org/2008/09/11-rdfa-minutes.html#action15]
-> Discussion with Ian and Henri about HTML5+RDFa (part 1/2) [Manu 2009-01-19]
-> Discussion with Ian and Henri about HTML5+RDFa (part 2/2) [Manu 2009-01-19]
Manu: there was less opposition than I'd
expected
... but demonstrated use cases are important
... may need to assume less familiarity with RDF when describing the use
cases
... details of RDFa aren't familiar to most folk I've talked with; CURIE
seemed to trigger most concerns
... Henri Sivonen said he'd be willing to accept RDFa if it dropped CURIEs
... other concerns about @rel and @rev unrelated to RDFa
Manu: @rev historically misused so some feeling that it should be removed from HTML5
Shane: next step?
Manu: I thought I'd add "Why" to each use
case
... present the use cases with Why to WHATWG
... Ian H said he'd take a thorough look at this
... I have already started adding Whys to the wiki
Mark: I wrote a blog
post about some of these topics
... I mention a few bits of history, back to an event in 2004
... crossing-over with Accessibility and device independence/content
adaptation
... I did a presentation on behalf of the XHTML WG talking about @role
... other presenters proposed extensions to HTML for content adaptation
... they liked the direction the XHTML WG was taking
... these supporters haven't been writing to the HTML WG list
... but the fundamental philosophical difference over extensibility between
the two communities may be the overriding factor
Manu: we had the same discussion in
Microformats about RDFa
... some, like Toby, have moved to RDFa; not all are yet posting
... discussion allows people to see the arguments and make up their own
minds
Mark: thanks for continuing to pursue this
Manu: so I'll continue on my project to add Why to each use case and then point the HTML WG / WHATWG at this
Manu: we've talked about splitting @prefix from
the token specification mechanism
... Ivan says he sees @prefix as an analog to @xmlns
... Mark has suggested that where @prefix is used (HEAD or BODY) could be
significant
Mark: one of the problems with the simple
analog is that this forces us into the simple hierarchical model
... a long time ago there were discussions with (Reuters?) about using
RDFa
... one of their use cases was documents, especially small ones -- consider a
twitter post -- that may require lots of namespace declarations
... would like an xinclude-like mechanism
... there's currently no way to use xinclude for this
... so simple analogue doesn't offer a solution
... I suggest that people may consider documents to be like programming
languages; HEAD is an initialization section
... an alternative is to say that prefix declarations _only_ are done
externally; @profile works like this
... so the declarations apply to the entire document
Shane: with local overrides if you want
... a hybrid of @xmlns and @prefix
Mark: but if we insist on @profile then we
don't have local overrides
... and if we say @profile is equivalent to @xmlns then we're locked-in to a
strict hierarchy
Shane: I think we can divorce @prefix from this
other problem
... we could have another set of rules, independent of @prefix and @xmlns,
for loading a set of declarations
Manu: I think we can separate these issues
... if we were to permit @profile on any element, we'd get the ability to
pull in from anywhere
Shane: so <head @profile> could apply to the entire document and @profile on any other element applies only locally?
Manu: makes sense to me that HEAD applies to the whole document but I haven't really thought about this deeply
Mark: I think we can make this backwards
compatible
... although @profile is not currently well-defined in HTML, it _does_ say
the URI is used with the values of @rel and @rev
... this implies that the profile does apply to the body as well as the
head
... consider CSS rules; the stylesheet is loaded in the head and applies
throughout the body
... we can also consider the form of the external document; my preference is
for it to be an RDFa document
... it could be just a collection of XMLNS declarations
... could propose that the triples loaded from @profile go into a separate
graph
... so there's the triples from the base document and a separate graph that
helps you interpret the base document
... a graph that helps you parse itself is a bit Goedel-esque :)
... it feels to me that things that help you parse the current document
should be a bit out-of-band
... I definitely don't think <meta @rel='profile'> is a good idea, nor
<meta property="prefix" ...
Manu: restricting ourselves to tokens and namespaces is good but bad to go beyond that
Manu: what else do we have in RDFa that applies to the body when it appears in the head?
Shane: nothing else
... the head section gives the properties of this document
... <title> a good example
Manu: so @prefix in the HEAD applies to the
body
... what about <html @prefix> ? would this work exactly like @xmlns?
Shane: sure
... if either @prefix or @xmlns appears on <html> and we _also_ load a
profile, what is the processing order?
Manu: I'd expect @prefix to always override an
external document
... same as @xmlns; it's a local override
... so profile is loaded first, then you apply the prefixes
Shane: sounds logical but thinking in terms of
the XML processing model you effectively have to process the document in the
order you're given it
... so how would we deal with <html prefix><head prefix=
profile="> ... ?
Mark: could just mirror what CSS does
... not necessarily right or wrong but it's a pattern people are already
familiar with
Manu: we do have a precedent for saying some
elements are processed before others
... our processing rules would effectively say to load @profile first then
process @prefix and @xmlns
Ralph: what if @profile appears lower in the tree?
Mark: when you have finished processing HEAD,
don't undo everything you've set when you start to process BODY
... @xmlns is all about the hierarchy but we want HEAD to be special
... two choices; retain HEAD settings in the BODY or
... but after finishing HEAD, when starting BODY do you go back to HTML or
not?
... these rules can be discussed
... we need to decide what's at the URI that appears in @profile?
Manu: should be an RDFa document
... that makes the most sense; otherwise we'd be inventing another mechanism
for doing the same thing RDFa already does
... for example, you should be able to copy and paste the content of that
profile document into the top of your current document and get the same
result
Mark: but I think the profile declarations should go into a separate graph
Manu: that could also make sense
Shane: I would never suggest that resolving the
profile URI should add triples to the document graph
... all I want is the prefix bindings
Mark: take a look at OWL's import mechanism
too
... so a document could use owl:import if the processor allows
... agree that the triples from a profile should be kept separate
Manu: we seem to have consensus to use
@prefix
... acts just like @xmlns except that if used on HEAD it applies to the
entire document
... remaining issue is the separator in the value of @prefix
Mark: do we need @prefix in HEAD?
... if we agree that whatever bindings exist at the end of processing HEAD
are preserved ...
... we only need to process the profile document first
... ah, but you could have <meta property='dc:title' prefix=...>
... but I think best practice would be to declare prefix on the html
element
... so the remaining question is about processing external documents
... agree that @prefix on HEAD applies to the entire document but our
examples should show best practice as using @prefix on <HTML>
Manu: the downside is that @prefix is then slightly different from @xmlns
Mark: and we'll also specify the value syntax
for @prefix to be very different from @xmlns
... I recommend that we _not_ explain the @prefix mechanism by reference to
@xmlns
... we're saying here's another way of declaring _prefixes_, *not* another
way of declaring _namespaces_
... if the only reason for declaring a namespace is to get a prefix for,
e.g., a CURIE, @prefix is a nicer way to do this
Shane: in a separate context, someone submitted
a commment noting a complaint from a validator on an xmlns declaration for
XSI that was totally independent of RDFa
... the commentor conflated namespace declaration issues with RDFa
Mark: I'd like to see this called 'token' and move further away from the xmlns area
Manu: do we have enough now to start writing some test cases?
Ralph: please create a notation for our test suite to distinguish these design tests from the approved RDFa-REC tests
Manu: sure
... also need a way to talk about the two graphs; the document graph and the
prefix binding graph
Mark: and consider whether there is a
well-known identifier for this separate graph
... should we define a name for it?
Shane: I think we can just say the triples do
not go into the document graph
... we don't have to require that the triples do go into some other graph
... e.g. some processor might not create an explicit graph
Mark: discussions of who [author, publisher, ...] adds metadata to documents
Shane: perhaps the graph could be named by the URI of the source?
Mark: yeah, something like that
ACTION: Manu to create design tests for @prefix and @profile. [recorded in http://www.w3.org/2009/01/22-rdfa-minutes.html#action16]
Manu: regrets for 5 Feb telecon
[adjourned]