See also: IRC log, previous 2007-04-23
ACTION: Ben to discuss Primer and Use Cases as Note, Syntax and Test Cases as REC, at SWD WG meeting [recorded in http://www.w3.org/2007/04/16-rdfa-minutes.html#action14] [DONE]
Ben: I was supposed to followup with an email summarizing the status
ACTION: Ben send email to SWD WG list summarizing RDFa document status [recorded in http://www.w3.org/2007/05/31-rdfa-minutes.html#action02]
ACTION: Ben to schedule new telecon time starting May 7 [recorded in http://www.w3.org/2007/04/23-rdfa-minutes.html#action18] [DONE]
ACTION: Mark to write up a consistent story on the @SRC attribute [recorded in http://www.w3.org/2007/04/23-rdfa-minutes.html#action17] [CONTINUES]
ACTION: Ben start a list of RDF/XML features that are not supported by RDFa [recorded in http://www.w3.org/2007/01/23-swd-minutes.html#action01] [CONTINUES]
ACTION: Ben to ask W3C about XML-DTD validation [recorded in http://www.w3.org/2007/04/16-rdfa-minutes.html#action19] [CONTINUES]
ACTION: Ben to flesh out the schedule and present for everyone's approval next week. [recorded in http://www.w3.org/2007/04/16-rdfa-minutes.html#action17] [CONTINUES]
ACTION: Ben to look into Science Commons use case [recorded in http://www.w3.org/2006/12/11-htmltf-minutes.html#action04] [CONTINUES]
ACTION: Ben to take a look at http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Jun/0001.html to see if issue has been resolved [recorded in http://www.w3.org/2007/03/12-rdfa-minutes.html#action17] [CONTINUES]
ACTION: Elias to send email to list with use case from IBM [recorded in http://www.w3.org/2006/12/04-htmltf-minutes.html#action10] [CONTINUES]
ACTION: Mark produce more examples of applicability of n-ary relations from IPTC documents [recorded in http://www.w3.org/2006/10/23-htmltf-minutes.html#action08] [CONTINUES]
Mark: that's connected to whether we drop reification
ACTION: MarkB to work rdf:label back into RDFa syntax when using @content [recorded in http://www.w3.org/2007/03/19-rdfa-minutes.html#action25] [CONTINUES]
ACTION: MichaelH to do partitioning of TCs, freeze the XHTML1.1+RDFa, and invite implementors to comment. [recorded in http://www.w3.org/2007/04/16-rdfa-minutes.html#action13] [CONTINUES]
ACTION: Steven to put together sample XHTML2 doc with all mime type, etc. [recorded in http://www.w3.org/2006/09/19-htmltf-minutes.html#action01] [CONTINUES]
ACTION: Wing add a property to the test case schema for tracking origin and approval of an individual test [recorded in http://www.w3.org/2007/03/05-rdfa-minutes.html#action11] [CONTINUES]
Steven: there were lots of talks at WWW2007 in
which RDFa was mentioned
... I noted them on rdfa.info
... I was pumped that there was so much going on
Ralph: +1
Steven: it was great to see how much was being done with RDFa
Ralph: there were several talks using RDFa from
people I didn't know were using it
... my reaction was 'we should just finish this quickly with minimal
changes'
Steven: we shouldn't keep it a moving target
... Fabien mentioned RDFa in his GRDDL talk
Mark: things are speeding up
... people doing RDF work when they want to do something that relates to HTML
will consider microformats, e-RDF, and RDFa and seem to be seeing why RDFa is
more useful
... FireFox operator support for RDFa is an indication of adoption
... Elias' presentation was one of the clearest I've heard
... Elias didn't focus on the syntax
... Elias went directly to 'what does RDFa do for you?'
... value proposition was very clear
Steven: Elias showed how easy it is to add a
new vocabulary
... operator adds things like add-to-calendar for microformats; Elias showed
the same thing for RDFa
Ben: primer is more-or-less stable, with a few comments
Steven: urgent that we add @REV
Ben: we'll likely have to add @RESOURCE also
Steven: we've already decided @REV so it's high
priority to include it in the primer
... I'm working on the syntax document
Ben: I can be ready to resume editing on syntax
document in a couple of weeks
... the source is the XMLSPEC (.xml) version
Steven: the work on the syntax doc is to bring it up-to-date w.r.t. our decisions
Mark: I'm willing to help work on the syntax doc
Ben: we should aim to be done before
November
... if SWD has a f2f in November, that should be the last WG vote we need
-> PROPOSAL: Split RDFa into two pieces--core attributes, plus language-specific 'interpretations'
Mark: this proposal is more about a mindset
... Ben captured the essence in one of his replies
... having a structure may give us a framework for making decisions more
quickly on issues such as @HREF everywhere
... criteria for deciding
... propose that changing the host language is out of scope
... but we have more flexibility with new attributes we create
... so mindset is to distinguish between attributes that already exist in the
host language and new attributes we've added
... future host languages, e.g. XHTML2, can learn from RDFa experience and
adopt features
... core document describes key features
... syntax document is effectively a dialect for a specific host language
Steven: concerned if the genericity would be
lost; could one still implement a generic RDFa processor that is host
language-independent?
... wouldn't like to add special rules for particular languages
... not sure that it makes sense to talk about a 'host language'
... unless we put attributes into a separate namespace, what's the notion of
a host language?
... @ABOUT doesn't exist in XHTML1.1, for example
... I've always viewed these as a coherent set of attributes, designed for
XHTML2
Ben: if we follow this rule, @REL everywhere also doesn't work
Mark: yes, just as you've argued against @HREF everywhere
Ben: my argument against @HREF everywhere is
that authors expect @HREF to be clickable
... if there's an @HREF that is not human-navigable, does this start to make
a separate RDF navigation branch different from the human-navigational
branch?
... @HREF on a span would only be there for RDFa, not for human navigation
... this is the start of parallel metadata rather than marking-up what the
user already sees
Steven: I say this is a feature; if you want clickable behaviour, use A, otherwise if you're happy that it's not clickable, use some other element
Ben: as an HTML author, if I want to mark up
existing text as data I can add @REL
... but using @HREF on a SPAN that isn't clickable is purely for the machine,
not for the human
... like LINK in HEAD
... separating human stuff from machine stuff
Steven: the semantics don't disappear; the
browser could still do something, such as provide a menu
... it only happens not to be clickable at the point in the page
... if the author wanted it clickable, she would have used A
Mark: what's confusing to me is that the
criteria for changing the syntax are currently hard to nail down
... one person's "easy" is not easy or obvious to another
... in the past few days we've found examples, like Joost and Yahoo!, where
authors are using @HREF exactly as it's intended
... we're having difficulty agreeing on this, so my proposal is to rely on
the host language for the interpretation
... if host language allows @REL everywhere, fine
... the additional attributes we invent can have more general rules
... so if we want @REL everywhere, we'd need to add our own REL attribute
Ben: I admit there's some logical inconsistency
versus starting fresh with a clean design
... no one has said that @REL everywhere is problematic
Mark: but it's the same issue with @HREF everywhere
Ben: I liked @RESOURCE as a solution; I think
of @RESOURCE as parallel to @CONTENT
... CONTENT="..." is an indication of a need to override the human-readable
text with different machine-readable version
... @RESOURCE is similar; the author can't easily make the human=readable
form clickable
Mark: gets into issues I didn't want to bring
up right now
... rdfs:label is about preserving contents
... mirror situation is that @RESOURCE and @HREF on the same element should
both be parsed
... RDFa core does not have a notion of 'clickability'
... moving up to the HTML layer we find attributes that may have RDFa
interpretations
... we can decide which of the HTML features have an RDFa interpretation
... @REL and @REV are in HTML space and we can define their RDFa
interpretation
... the profile (dialect) can say whether @REL is permitted everywhere
Ben: trying to consider this from the viewpoint
of HTML, acknowledging that I'm not an HTML expert ...
... consider a chunk of HTML today that has <SPAN HREF="...">
... today that is not clickable.
... if it becomes clickable in XHTML2, that might not be what I wanted
Steven: 'clickable' does not necessarily mean
the XHTML2 browser would render it in blue with an underline
... don't confuse the ability to dereference an @HREF with the rendering
presentation
... only A would give blue underlined presentation
Mark: I think @RESOURCE is the best solution
anyway
... if we have @HREF as the definer of the object then we have no way of
defining an object that is not clickable
... so reintroducing @RESORUCE gets us out of this
... more broadly, it would help us to have a better sense of which level
we're playing with when we discuss a change
Ben: every time we've been forced to
compromise; @REL has felt so 'right' to many people
... we've had to deal with varied expectations of HTML
... and we have had to consider the general public's reaction even if we
don't know how to measure it very carefully
Mark: I'm not necessarily opposed to @REL
everywhere, just trying to point out the proposed core principle
... I'm suggesting that @REL should not be a core RDFa attribute; it remains
an HTML attribute to which we give an RDFa interpretation
... and instruct Shane that when he produces a DTD, in addition to adding
@ABOUT, etc., he permits @REL, @REV everywhere
... we don't necessarily have to restructure the documents to identify 'core'
vs. 'host' features
... currently the only cases where we modify HTML are @REL and @REV
everywhere
Ben: what will the XHTML2 specification recommend to browsers when they find @HREF on a SPAN?
Steven: the browser shouldl make the @HREF accessible in some way but not as a blue underline; only A should render as a blue underline
Ben: that makes me more comfortable
... but if RDFa proposes @HREF everywhere that still feels like we're
stepping into the scope of HTML
... whereas @REL everywhere doesn't have any [rendering] behavior
Ben: there seems to be support for this on the list
Steven: I see it as a complication
... sometimes you have to use @resource and sometimes @href so you need a
rule to know which to use
Mark: I'm suggesting that both would be parsed
Steven: I prefer to use @HREF everywhere
... we can't ask for this behavior in XHTML 1.1
... all that's happening in XHTML2 is that the spec will ask the browser to
let the user do _something_ with @HREF on SPAN
... XHTML2 will just make the content a little more accessible to users
Mark: but there would be no way to create a
non-clickable resource
... Ben argued at length against having to repeat the data in @HREF
... my view now is that @HREF is a special case of @RESOURCE
... @RESOURCE is abstract, purely about the metadata
... @HREF makes it accessible to the user
Steven: perhaps we need a URI scheme that signals that something is *not* dereferencable?
Ralph: I hope you mean that as a joke
... perhaps we have different notions of what "dereference" means
Ben: let's progress the discussion in mail
Ralph: do we have a clear place where our open issues are documented?
Ben: We're using tracker
ACTION: Ben to review tracker issues and add @resource, @href, @src, profile if not there already [recorded in http://www.w3.org/2007/05/31-rdfa-minutes.html#action16]
next meeting: next week (June 7), same time (1500 UTC)
[adjourned]