See also: IRC log
<AndyS> Ref: http://rfc.net/rfc3987.html#s3.
<LeeF> Scribe: jeen
<AndyS> better: http://rfc.net/rfc3987.html#s3.1. just before 3.2
<LeeF> ericP, you coming along?
<LeeF> minutes from 24 Apr -> http://www.w3.org/2007/04/24-dawg-minutes.html
<LeeF> minutes approved, seconded by jeen
<AndyS> Off topic: Joost launch: RDF in action! http://news.bbc.co.uk/1/hi/business/6612199.stm
<LeeF> next meeting, 8 May, scribe @@
<LeeF> ACTION: ericP to respond to Jeremy Carroll's comments re: langMatches [DONE] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action01]
<LeeF> ACTION: ericP to respond http://www.w3.org/mid/4617D68D.4010608@hp.com [DONE] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action02]
<LeeF> ACTION: EricP to run the yacker tool over and annotate the existing tests [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action03]
<LeeF> ACTION: ericP to get in touch with SteveH re: setting up an environment to generate an Overview page for tests in data-r2 a la http://www.w3.org/2001/sw/DataAccess/tests/ [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action04]
<LeeF> ACTION: ericP, jeen, or LeeF to update http://www.w3.org/2001/sw/DataAccess/tests/README with info on possible results format and on changes to manifest and test vocabularies [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action05]
<LeeF> ACTION: ericP to write a test showing that langMatches doens't do extended matching [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action06]
<LeeF> ACTION: LeeF or EliasT to reply to Bjoern regarding (not) POSTing application/sparql-query documents [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action07]
<LeeF> ACTION: LeeF or EliasT to reply to Bjoern regarding (not) POSTing application/sparql-query documents [CONTINUES[ [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action08]
<LeeF> ACTION: LeeF to mark the 4 regex tests approved [CONTINUES] [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action09]
LeeF: discussed this last week, consensus seems no technical objections against allowing
<SimonR> I do have a technical reason against it.
LeeF: I was going to check whether this would be substantive enough to need a new LC
SimonR: I did have a technical objection, you can put it in a construct and thus produce something which is not a legal XML QName in your output graph
<chimezie> i don't see how expanding 'qname' lexical form will be problematic for serializing RDF/XML
<chimezie> via CONSTRUCT
EricP: if the data is there in the first place, it can already occur in the output of a query, so we are not introducing a _new_ problem.
<AndyS> Example: x:0123 becomes <http://example/ns/0123> as a property which is not qname-able in RDF/XML.
<chimezie> ahh, thx
SimonR: I'd be inclined not to change the spec and be conservative. but the world won't fall if we do allow this.
<AndyS> Can do it in other ways - this makes it a bit easier to do.
LeeF: EricP talked to Ralph (and
Tim). according to him it is a substantive change.
... but we could mark it as 'at risk', reserving the right to
remove in PR if we want.
<LeeF> AndyS: neutral
<LeeF> SimonR: do nothing
<LeeF> jeen: neutral
<LeeF> chimezie: add it at-risk
<LeeF> ericP: add it at-risk
<LeeF> Souri: add it at-risk
SimonR: can we explain in the spec why it is at risk?
LeeF: we have no obligation to do that, at least.
<LeeF> PROPOSED: To accept leading digits in the local part of a prefixed name and mark this as a feature at-risk in the sepcification
seconded by AndyS
<LeeF> so resolved.
RESOLVED, no abstentions or objections
<SimonR> I'm willing to write some text explaining the issues around leading digis.
<LeeF> ACTION: SimonR to write text explaining the leading digits at-risk feature [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action10]
<LeeF> ACTION: AndyS to update the grammar for leading digits [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action11]
<LeeF> ACTION: chimezie to write up a test case showing leading digits in local part of prefixed names [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action12]
<LeeF> issue inspired by comments in http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2007Apr/0007.html
<SimonR> Do we have a way in the test suite to express an "at risk" feature? I'm presuming at the moment our tests are supposed to either succeed or fail. Do we have any marked to only work in the case of a optional feature? (Exntailment regimes, user-defined functions, etc?)
<chimezie> i *think* the current test suite uses 'vanilla' RDF test vocabulary, so I don't think so (currently)
<jeen> simon, i don't think we do
<SimonR> Okay, so there might be some test suite framework extension required, as well as writing the tests themselves.
<chimezie> IRI specification includes certain characters which would cause conflicts in our grammar (< for instance)
AndyS: in favor of maximizing interoperability by keeping out that excluded-char list
<AndyS> Example: <http://example/a{b}c> seems to be a legal IRI but not a URI.
<SimonR> Is RDF core officially using IRIs yet? (Probably a silly question, but I might as well ask.)
LeeF: my inclinination would be to stick to as close as what we have right now, and keep the exclusion list
<AndyS> RDF core is not using IRIs because it predates RFC 3987
Souri: also in favor of sticking with as-is
<chimezie> if there is no technical pushback is seems prudent to go in teh IRI direction
<chimezie> as thit seems to be the general consensus direction
jeen: not sure about changing this without taking a good look at consequences for current parsers first.
<AndyS> Chimezie - just an observation - the arg could be to go for the most conservative as well. This is tricky.
<chimezie> yes, the uncertainty for me is mainly what hiccups (if any) it introduces
<SimonR> You know, if we delimited our prefixed named with <> and left IRIs delimited by whitespace, we might dodge this. Probably to confusing to consider, but <> would be no issue for pseudo-XML characters.
<SimonR> to/too
<AndyS> Jeen - SeRQL uses {} for delims doesn't it?
<Jeen> Andy - delims around subject and object (i.e. graph nodes as opposed to edges) . uris are delimited with <> same as in SPARQL
<AndyS> Jeen - thanks
<Souri> What are the characters? <,>,{,}, space, ...
<AndyS> Souri: "<", ">", '"', space, "{", "}", "|", "\", "^", and "`"
<AndyS> (from RFC 3987 near end sec 3.1)
<Souri> Thanks Andy.
<LeeF> somewhat accurate comment report
<LeeF> #2 has been fixed, #3 is a question, #1 is mainly a question
LeeF: we have pretty much
addressed all the LC comments (only have to send one more
reply)
... still hoping to move to CR next week
LeeF: I will go through old objections and summarize their status
<LeeF> attributes in results format
LeeF: question on whether we need
additional reduced attribute in XML format triggered discussion
on under-specification on meaning of distinct attribute
... so the broader question is whether we need a reduced
keyword and whether we need to keep the distinct and ordered
keywords in the result format?
<ericP> my vote: wipe them all out
<LeeF> Is anyone in favor of keeping the distinct= and ordered= attributes?
<Souri> I too favor removing them
Chimezie: I'm in favor of removing as well
LeeF: we seem to have consensus on this
<LeeF> PROPOSED: To remove the ordered= and distinct= attributes from the SPARQL Query Results XML Format
second by jeen and andy
RESOLVED, no abstentions or objections
<LeeF> ACTION: jeen to remove ordered and distinct attributes from the query results xml format editors' draft [recorded in http://www.w3.org/2007/05/01-dawg-minutes.html#action13]
ADJOURNED