See also: IRC log
<trackbot> Date: 04 March 2010
<Benjamin> hi
<ShaneM> low tech crap
<ShaneM> Scribe: ShaneM
<manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0007.html
<manu> trackbot, Action-3?
<trackbot> Sorry, manu, I don't understand 'trackbot, Action-3?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<manu> trackbot, ACTION-3?
<trackbot> Sorry, manu, I don't understand 'trackbot, ACTION-3?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<manu> ACTION-3?
<trackbot> ACTION-3 -- Manu Sporny to get in touch with LibXML developers about TC 142 -- due 2010-03-11 -- OPEN
<trackbot> http://www.w3.org/2010/02/rdfa/track/actions/3
<manu> ACTION-10?
<trackbot> ACTION-10 -- Manu Sporny to get Toby to fill out Invited Expert form. -- due 2010-03-04 -- OPEN
<trackbot> http://www.w3.org/2010/02/rdfa/track/actions/10
<manu> trackbot, close ACTION-10
<trackbot> ACTION-10 Get Toby to fill out Invited Expert form. closed
<tinkster> thanks
<manu> trackbot, comment ACTION-10 Toby is now an Invited Expert to RDFa WG
<trackbot> ACTION-10 Get Toby to fill out Invited Expert form. notes added
<manu> ACTION-11?
<trackbot> ACTION-11 -- Shane McCarron to suggest short names for each working group deliverable -- due 2010-03-01 -- OPEN
<trackbot> http://www.w3.org/2010/02/rdfa/track/actions/11
<tinkster> http://www.w3.org/mid/4B882B19.6030104@aptest.com
<manu> http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0095.html
<tinkster> W3C list emails contain an "Archived-At" header in the message headers.
ivan: agrees with the suggested shortnames. some issue with how data should be organized.
<manu> trackbot, close ACTION-11
<trackbot> ACTION-11 Suggest short names for each working group deliverable closed
<manu> http://www.w3.org/2010/02/rdfa/track/issues/4
<manu> scribenick: manu
ShaneM: The XHTML+RDFa family
spec has settled on XML1.0 4th edition, which is not the
current publication
... 5th edition is the latest version.
<tinkster> What about other current/potential host languages (e.g. SVG)?
<Steven> nmchar
ShaneM: This is already fixed, it was a typo in the spec, it's addressed in the errata and is fixed in the draft.
trackbot, close ISSUE-4
<trackbot> ISSUE-4 Determine the proper XML namespaces document to refer to in the RDFa specification closed
<tinkster> SVG 1.2 Tiny uses XML 1.0 4th Ed; Namespaces 1.1 2nd Ed.
trackbot, comment ISSUE-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated.
<trackbot> Sorry, manu, I don't understand 'trackbot, comment ISSUE-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated.'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
trackbot, note ISSUE-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated.
<trackbot> Sorry, manu, I don't understand 'trackbot, note ISSUE-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated.'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<Steven> trackbot, help
<trackbot> See http://www.w3.org/2005/06/tracker/irc for help
<tinkster> I have a third proposal - similar to Manu's http://www.w3.org/mid/1263324223.22239.49.camel@ophelia2.g5n.co.uk
<Steven> You use trackbot, comment action-127 something
http://www.w3.org/2010/02/rdfa/track/issues/1
<Steven> 01trackbot, comment ISSUE-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated.
http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0016.html
<Steven> trackbot, comment issue-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated
<trackbot> Sorry, Steven, I don't understand 'trackbot, comment issue-4 The references section in the XHTML+RDFa errata and the RDFa Core 1.1 document have been updated'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<tinkster> http://www.w3.org/mid/1263324223.22239.49.camel@ophelia2.g5n.co.uk
<ShaneM> tinkster: similar, but generates fallback triples if the vocabulary document can't be dereferenced
<ShaneM> manu: are you asking that we consider this proposal as well?
<ShaneM> tinkster: It is really just refinements to Manu's proposal - it would be transparent to end users. It allows the definition of a default prefix in a document.
<ShaneM> ivan: tinkster's proposal is really incremental to EITHER of the basic proposals.
<ShaneM> ivan: describing the two basic proposals. mark's proposal has multiple formats. Not a fan of the implementation burden of supporting JSON and RDFa as basic formats.
<ShaneM> manu: prefers aspects of Mark's proposal.
<ShaneM> Essential differences are that Mark's proposal permits declaration of prefixes and keywords.
<ShaneM> ... concept that there is a default vocabulary is a new concept, but one that lots of people seem to like.
<ShaneM> ... profiles proposal allows for recursive inclusion. Vocabulary proposal does not.
<ShaneM> ... vocab proposal defines a new attribute @vocab. profile proposal relies up @profile being in host languages
<ShaneM> ... @profile is not currently a part of HTML5. If HTML5 adopts @profile everywhere, then we could rely upon that. If it does not, we would need to use a different name.
<ShaneM> ... Other items that should be in: Default RDFa Vocabulary / Profile. Mark has indicate that the default should ONLY be used if a page does not specify a profile. If there is a profile specification, then it should be used instead of any default profile.
ack [IP
<Zakim> [IPcaller], you wanted to review the high-level differences between both proposals.
<ShaneM> ivan: Would prefer to postpone the discussion of the default profile. If we have a mechanism for specifying a vocabulary, then we can think about how to deal with default profile.
<ShaneM> ... it would be trivial to add the definition of 'prefixes' to the vocab proposal.
<ShaneM> ... it is much more interesting for me to have a default definition for 'foaf:' is more important than defining the individual keywords that make up FOAF.
<ShaneM> manu: yes, it is possible to extend the vocabulary proposal to support prefix declarations.
<ShaneM> ... has reservations about using xmlns: to declare prefix mappings.
<Steven> I disagree with that interpretation
<ShaneM> manu: We should stop overloading xmlns: - declaring tokens with it is an abuse of xmlns.
<Steven> that bit I agree with
<ShaneM> ivan: he agrees that this is a hack. Also, xmlns defines prefixes for the file that is being processed. Having those declarations leak into another document is inconsistent.
<ShaneM> ... if I have a vocabulary document and I want to document the document itself, then I might want to use RDFa to do that documentation and bring in other vocabularies. Those vocabularies should not leak into the document that is USING the vocabulary.
<ShaneM> Steven: disagrees that an xmlns declaration introduces a namespace. All xmlns does is declare a prefix mapping and then to scope elements and attributes later.
xmlns: Person="http://..../#Person"
<tinkster> It's a neat hack, but it's still a hack.
I don't agree with doing that.
<ShaneM> Steven: Whatever we do needs to be easy for authors. They shouldn't be required to understand mystical aspects of namespaces.
<ShaneM> No one seems to support overloading xmlns in this way.
<Zakim> ShaneM, you wanted to talk about how xmlns is used
<tinkster> +1
<ShaneM> manu: Just to clarify: we don't want to overload xmlns to declare tokens and prefixes in vocabulary documents. Additionally, we WANT to use RDFa to declare terms and prefix mappings in the vocabulary documents.
<ShaneM> ivan: Well, isn't that the next topic? We were going to discuss JSON
<Zakim> ShaneM, you wanted to address the JSON issue
<ShaneM> manu: the one really positive thing that JSON does is it COULD allow us to not rely upon CORS support in browsers in order to make it work.
<tinkster> no json does not allow workaround for cors - jsonp does.
Toby is right.
<tinkster> jsonp is a dialect of javascript so theoretically introduces security issues
<ShaneM> ShaneM: no reason to preclude having a JSON version of the vocab come out via content negotiation. Basic format should be RDFa.
<ShaneM> manu: There is a possibility of fragmentation then. And that's bad.
<ShaneM> ShaneM: I know... And I don't really care.
<ShaneM> ivan: my concern is implementations. there is a cost associated with supporting multiple formats. Also, what is the security concern?
<tinkster> sorry can't speak right now
<tinkster> can post to list later.
ok, thanks Toby.
<Benjamin> http://en.wikipedia.org/wiki/JSON#JSONP
ack [IPCa
<Zakim> [IPcaller], you wanted to discuss CORS.
<ShaneM> ShaneM: The issue is that if you are bringing in a javascript resource from OVER THERE and OVER THERE gets compromised, then badness could ensue
<tinkster> Got to go, but please give me an action to post a writeup of JS/JSON/JSONP/CORS to list.
<ShaneM> manu: There is also the cost of maintaining the JSONp file and keeping it in sync. The alternative is that you enable CORS support. Supporting CORS is potentially easier than maintaining multiple documents.
<Steven> trackbot, status
<Steven> ACTION: Toby to 01post a writeup of JS/JSON/JSONP/CORS to list. [recorded in http://www.w3.org/2010/03/04-rdfa-minutes.html#action01]
<trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
<trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
<ShaneM> ivan: My understanding is that the implementor can choose which format to provide.
ack [IPc
<Zakim> [IPcaller], you wanted to discuss RDFa /OR/ JSON
<Steven> ACTION: Toby to post a writeup of JS/JSON/JSONP/CORS to list [recorded in http://www.w3.org/2010/03/04-rdfa-minutes.html#action02]
<trackbot> Created ACTION-14 - Post a writeup of JS/JSON/JSONP/CORS to list [on Toby Inkster - due 2010-03-11].
<ShaneM> ... I was opposed to that because it means an RDFa parser needs to understand multiple formats. But if it enables the javascript implementation, then it might be okay to support JSON.
<ShaneM> manu: Feels that the server MUST support vocabularies in both formats. If what we are trying to do is make it easy for implementors, then we want to have an RDFa mechanism all the way through. The only reason is to have the JSON support is to help javascript implementations. However, that problem can also be solved via CORS. But CORS is not widely distributed yet.
<ShaneM> ivan: Need to make things easy for authors. Implementors can work a little.
<ShaneM> manu: If RDFa API works out or CORS takes off, then we don't need to worry about marking things up in JSONp
<Steven> ack [IP
<Zakim> [IPcaller], you wanted to discuss RDFa API
<ShaneM> manu: we need to get general agreement from Mark and Ben about what we discussed today.
<ShaneM> ivan: Is it okay if we extend the vocab proposal so it includes prefix declarations too.
<ShaneM> manu: sure
<ShaneM> ivan: okay - will do that tomorrow and will put it in W3C space
trackbot, help
<trackbot> See http://www.w3.org/2005/06/tracker/irc for help
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/ossues/issues/ Found Scribe: ShaneM Inferring ScribeNick: ShaneM Found ScribeNick: manu ScribeNicks: manu, ShaneM Default Present: Knud, +0785583aaaa, RobW, Ivan, Benjamin, [IPcaller], mgylling, tinkster, ShaneM, Steven, manu Present: Knud +0785583aaaa RobW Ivan Benjamin [IPcaller] mgylling tinkster ShaneM Steven manu Found Date: 04 Mar 2010 Guessing minutes URL: http://www.w3.org/2010/03/04-rdfa-minutes.html People with action items: toby WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]