- From: Kevin D. Keck <kdkeck@lbl.gov>
- Date: Mon, 14 Jul 2003 09:08:24 -0700
- To: Sandro Hawke <sandro@w3.org>, timbl@w3.org
- Cc: www-rdf-interest@w3.org
On Monday 14 July 2003 06:20, Sandro Hawke wrote: > > > The current solution is mapping sequences of "-" and "_" into sequences > > > of "_" > > > by taking a contiguous sequence of - and _, replacing _ with 0 and - > > > with 1, > > > then adding a leading "1", taking what you have as a binary number, > > > subtracting 1 from the result, and then writing that many _ signs. > > > > But most damningly, the escape mechanism devised to address this issue is > > not only unwieldy and unfriendly, it is not even complete: how do you > > escape "a-to-_"? My guess is cwm would currently escape it as a__to___, > > which collides with the encoding of "a-to__". Not to mention the fact > > that many N3 parsers don't seem to implement "identifier munging" at all > > (see http://infomesh.net/2002/n3qname.html). > > I wouldn't argue this mapping was friendly or wieldy, but I'm not sure > you've proven it's incorrect: as I follow the algorithm, "-_" turns > into binary 10, prefix with 1 to get 110, subtract one to get five, so > we get "a__to_____". As far I can tell, cwm doesn't actually > implement any mangling, though, and there's nothing in the test suite > for it. Yeah, you're right, I mis-read the spec. Sorry. > > So here's hoping Tim is now ready to excise this wart from N3. If he were > > serious about banishing '-' from RDF IDs, he should have fought that > > battle a long time ago, back when RDF was being finalized. It would seem > > much too late for that now, so the sensible thing to do is just accept > > it, properly accommodate it, and move on. > > Why can't it be banished as a "best practice" instead of formally? > Kind of like using identifiers like x0d457e059624dc933b1566c4fe5da in > a C: it's allowed; it's just a really bad idea. Because I don't think you'll be able to forge a consensus at this point that '-' and '.' are truly bad to use, especially if many people have already decided to use them in their current schemas. > Meanwhile, I think forcing people to be careful with whitespace around > operators is an iffy proposition in a modern formal language. > > > And while we're at it, the same thing goes for '.'. I expect some will > > reflexively protest that the use of '.' as the statement terminator makes > > this problematic. They might have a leg to stand on if it weren't for the > > fact that '.' is already also permitted within numeric (rational) > > literals. > > "." is also being used as an infix path operator now, which I think > foils your plan. That's news to me. I can understand people disliking '!'. But why not use '/'? > Of course, this forces people to use spaces after the "." which ends a > sentence and not to use spaces after the "." which is an operator.... > So much for my "iffy proposition". :-) > > (I did once design a language which cared about whether you had spaces > between a term and an open paren, so (f (x)) was a pair while (f(x)) > was a function application, ... I managed to justify that to myself. > As I recall, Tim razzed me for it. :-) > > -- sandro > > [1] http://lists.w3.org/Archives/Public/www-rdf-interest/2003Jul/0112.html And again, the whitespace issue is moot if we can just stay away from operators that start with '-' or '.'. -- Kevin D. Keck http://vimss.lbl.gov/~kdkeck/ 510-486-4856
Received on Monday, 14 July 2003 12:08:33 UTC