Meeting minutes, 2009-11-29

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Meeting minutes, 2009-11-29

Ivan Herman-2
Minutes are at:

Text version below.





                        RDF in XHTML Task Force

19 Nov 2009



   See also: [3]IRC log



          Manu_Sporny, Ivan_Herman, Mark_Birbeck, Ben_Adida,
          Shane_McCarron, Steven_Pemberton

          Ben Adida



     * [4]Topics
         1. [5]Test Cases
         2. [6]Action Items
         3. [7]Working Group Charter
     * [8]Summary of Action Items

Test Cases

   we are doing these via e-mail, but there is a general topic.

   <Steven> put that in the record manu

Action Items

   Manu's action to confert the charter to HTML format is complete.

   <benadida> -->


   <benadida> ACTION: Manu to convert WG Charter page to W3C charter
   format [recorded in
   [10]] [DONE]


   <scribe> ACTION: Mark to author URIs in @about, @rel, @rev, @typeof
   and @datatype spec text [recorded in


   <scribe> --continues - nearly done

   <msporny> we should accept the test cases based on the current
   published rules and then change the test cases if we change the
   rules in the future.

   markbirbeck: original proposal said we should advise people to use
   safe curies.

   ivan and shane said why bother? It gets handled automatically.

   Ben seems to have opened the question again. So there seems to be an
   open issue. Should we encourage people to use safe curies or not?

   Also, what if a prefix name is used that collides with a scheme

   Steven says this is not a problem since if I meant it to be a
   prefix, it will always remain a prefix

   markbirbeck: if I edit that document later and am inserting a link
   that now uses some new scheme that collides with prefixes I declared
   ages ago, that could be an issue.

   benadida: As long as the document doesnt change meaning if the
   document is not edited later, it is not an issue

   ivan1: the chances for something like this to occur are non-zero,
   but it is so rare as to be uninteresting
   ... we should put in some warning

   markbirbeck: we could plug all holes if we insist on a safe curie.
   But if we are happy these edge cases are not a real issue, then
   let's leave it

   <msporny> I don't think we should ever depend on people correctly
   using Safe CURIEs

   <msporny> yes, I was in agreement with this direction.

   ivan1: if we keep to the priority in processing that we look to see
   if something is a CURIE or not, then this is backward compatible
   ... if we go one step further, we could have relative URIs in

   <msporny> I don't know if we should have relative URIs in @property
   - I realize the use case, but it's very uncommon.

   benadida: feels the use case is very rare.

   <msporny> I think the reason to forbid it is because it
   overcomplicates RDF.

   ivan1: agrees but doesn't seem to find a reason to forbid it.

   <msporny> s/RDFa\./RDFa./

   benadida: RDF/XML is an example of having many ways to write the
   same thing, and this makes it complicated to learn.
   ... if we have CURIEs and SafeCURIEs in the same datatype this is

   ivan1: thinks that we have inconsistency in our rules today between
   @rel and @rev vs. @about and @resource

   <msporny> That said, I would be in favor of playing down Safe

   markbirbeck: points out that we could downplay SafeCURIEs if we
   wanted too
   ... remarks that lately we have realized that if there is no defined
   prefix, it can be easily interpreted as a URI. that means there is
   less possibility for confusion.

   <msporny> I haven't seen Safe CURIEs used in the wild...

   benadida: if we are going this route, we should downplay the
   importance of SafeCURIEs
   ... Wants to wait to see Mark's proposed spec text before making a

   <msporny> other than through somebody in this task force.

   <Zakim> ShaneM, you wanted to discuss tag objections

   <msporny> we might want to revisit this with the TAG based on our
   new findings.

   ShaneM: points out that the reason we have SafeCURIEs is that the
   TAG said we cannot put CURIEs and URIs in the same attribute
   ... the TAG didn't want the possibility for confusion on the part of
   humans, not software.

   ivan1: for many people this is a stumbling block (using full URIs
   instead of CURIEs)

   ShaneM: we are conflating two issues

   benadida: yes, but the one flows into the other
   ... proposes we wait for Mark's wording on this (but admits Ben is
   the hold up!)

   ivan1: make it clear to everyone (including the TAG) that we do not
   intend to introduce this behavior for non-RDFa attributes such as
   @href and @src

   markbirbeck: we can consider this as an RDF interpretation of
   existing markup

   Steven: w.r.t. Ivan's remark Steven thinks if we do this people are
   going to expect it to work in @href and @src. The advantage of
   having two different notations

   <msporny> We're going to get severe push-back from HTML WG if we
   change @href and @src

   is that you KNOW it was not allowed in @href. Validation might spot
   an error today. Going forward there is no way that validation would
   catch the use of a CURIE in @href and @src

   benadida: But the browsers would not do it right... so page authors
   would notice immediately that their links didn't work

   ShaneM: at least if there is a SafeCURIE in @resource I would not be
   confused into thinking it was a URI.

   markbirbeck: That's not the point. The point is that a consumer
   might think that @href=SafeCURIE should woirk. and going forward
   @href=CURIE should work. And they won't!
   ... perhaps we should cross this bridge when we come to it.
   ... the reason this is back on the agenda is because of HTML5. And
   this change (full URIs just work) will help us get past the
   technical objection that some in the HTML5 community have raised.

   Steven: The issue isn't that we can say "we won't apply this to
   @href and @src" but that might not be compelling

   benadida: I dont see browser manufacturers implementing
   interpretation of CURIEs in @href and @src

   <msporny> We should ask the TAG directly.

   <msporny> I also think that the danger that Steven has outlined does

   <msporny> If there is a chance of surprising somebody with this
   change, I think it would be best to point it out.

   ivan1: we should ensure that if we are moving in this direction we
   inform the objectors to CURIEs that there will be this option in the
   next version.

   ShaneM: I personally would object to a change that permits CURIEs in
   places where we only permits SafeCURIEs

   benadida: thinks we ar econverging

   <scribe> ACTION: Manu to ask somebody to draft errata text,
   clarifying that prefixes cannot be '_' character [recorded in


   <msporny> I haven't done that yet

   I did this.


   <scribe> --done

   <msporny> Thanks Shane :)

   <scribe> ACTION: Ben to finish authoring RDFa WG charter. [recorded
   in [14]]


   <scribe> ACTION: Manu to aggressively push review of test cases via
   mailing list [recorded in


   <scribe> ACTION: Manu to try and find other interested parties in
   RDFa WG. [recorded in


   <scribe> ACTION: Shane to re-draft XMLLiteral errata text [recorded
   in [17]]


   <benadida> consider thew new XMLLiteral errata text:


   <benadida> +1

   <markbirbeck> +1

   +1 (obviously)

   <Steven> +1

   <benadida> RESOLVED to accept the XMLLiteral errata text

   <benadida> consider the _ prefix errata text:


   <benadida> +1

   <Steven> +1


   ivan1: why "SHOULD NOT" instead of "MUST NOT" for authors

   <ivan1> +1

   ShaneM: I have never seen a spec where we said "MUST NOT" to a spec

   <benadida> RESOLVED to accept the _ prefix errata text

   <markbirbeck> Abstaining. :)

   <markbirbeck> I have use-cases for redefining '_', but they're a
   little esoteric.

Working Group Charter

   ivan1: I made some edits and initiated some discussion within the
   W3C (management team etc.)
   ... for the time being it seems fine. Mike Smith suggested we make
   the Javascript API a higher priority.
   ... If everything goes well this week or monday we will let the AC
   know we are planning to move ahead with this charter.

   <ivan1> [20]


   ivan1: ... removed text that would cause people to be concerned
   about the open-endedness of the charter. The charter has specific
   deliverables. That should help assuage concerns about open-endedness

   <scribe> ACTION: Someone let Ivan know what Open Document Format
   reference to use in the charter [recorded in

   Steven: notes that we list coordination with external groups when
   they are outside of W3C.

   <Steven> Here is the ODF TC link -


   ivan1: pushed out milestones by a month because it assumed we would
   start in January, and that was not going to happen
   ... we could stretch the deliverables out to make it easier.

   benadida: the draft plans for slack time by having the schedule
   tight, but has the end of the charter out a little bit

   ivan1: we can extend the charter if we need to when deadlines are
   missed. dont' need to build in slack in this way.
   ... some deliverables in the charter look like software development.
   W3C working groups do not develop software. also, it looks like that
   is what the group would be doing in its last 8 months. that might be

   Steven: discussed the charter with the Interaction Domain team
   group. They felt we should be doing work on some basic set of
   advised vocabularies as a way to help people start using RDFa more
   ... Suggests we say we will produce a cookbook or produce standard

   ivan1: vocabularies is not an RDFa issue. it is a semweb issue. this
   group should not pick it up.
   ... having something that is richer than the Primer (e.g., a
   Cookbook) that uses some of the vocabs out there as examples might
   be a real benefit. We should not be blessing vocabs.

   <markbirbeck> +1 to Ivan

   Steven: I think a cookbook / examples is just fine and will help
   address their problem.

   ShaneM: +1 to Ivan

   ivan1: RDFa is a serialization syntax - vocab to use is a general
   sem web issue.

   re: software development...

   benadida: understands w3c is not in the software implementation
   business. However, when we started building prototypes of RDFa
   things really moved ahead.
   ... if we shouldn't put them in the charter that's one thing. but we
   should still prototype to ensure that things work!

   markbirbeck: not convinced things took off when we started
   prototyping. The problem is that mentioning specific libraries like
   jQuery or Dojo might be limiting. we should not be pushing a
   specific library set. We should have something more abstract but we
   should not lock ourselves in and therefore miss whatever is going to
   be happening two years from now.

   ivan1: +1 to Mark. moreover, saying we are adapting to jQuery or
   Dojo or whatever, that is something individuals are doing to ensure
   that the ideas work. It should not be a deliverable of the working
   group though.
   ... should have in the scope and deliverables more detailed text
   about community building. We have the Primer. We could do a note
   about triple store. There could be a cookbook. But we could also say
   that at the end of the working group we have a deliverable that is a
   Note about how RDfa is used in practice and what libraries are
   around at the time and how RDFa is used in the wild. This is the
   'start of the art' at the time.

   benadida: feels there should be implementation work, but if there is
   no room for it in the charter so be it

   ShaneM: is concerned that a Note at the end becomes some 'iconic
   thing' that gets referred to forever even though it is immediately
   out of date

   ivan1: What I try to do is set up wikis for groups so that it can be
   maintained over time, rather than just producing a Note. Make it
   explciit that there is also a wiki so the community can keep it up
   once the group ends
   ... knows there is already a wiki outside of w3c space.
   ... sem web wiki was just set up by Ivan. For the time being, in the
   sem web wiki there is apointer to the existing RDFa wiki.
   ... 'I am not in the business of trying to rule the world'.

Summary of Action Items

   [NEW] ACTION: Manu to ask somebody to draft errata text, clarifying
   that prefixes cannot be '_' character [recorded in
   [NEW] ACTION: Mark to author URIs in @about, @rel, @rev, @typeof and
   @datatype spec text [recorded in
   [NEW] ACTION: Someone let Ivan know what Open Document Format
   reference to use in the charter [recorded in


   [PENDING] ACTION: Manu to aggressively push review of test cases via
   mailing list [recorded in
   [PENDING] ACTION: Manu to try and find other interested parties in
   RDFa WG. [recorded in


   [DONE] ACTION: Ben to finish authoring RDFa WG charter. [recorded in
   [DONE] ACTION: Manu to convert WG Charter page to W3C charter format
   [recorded in
   [DONE] ACTION: Shane to re-draft XMLLiteral errata text [recorded in


   [End of minutes]

    Minutes formatted by David Booth's [31]scribe.perl version 1.135
    ([32]CVS log)
    $Date: 2009/11/20 10:27:15 $



Ivan Herman, W3C Semantic Web Activity Lead
mobile: +31-641044153
PGP Key:

smime.p7s (5K) Download Attachment