Re: Regrets for tomorrow's teleconf. and summary on DTB discussions.

1. Curie, <...>
My main concern with context sensitivity is that it will confuse people
(like it did several members of this group) to think that the stuff after
^^ are constants by themselves. This requires that we explain things
carefully and, possibly, will cause more confusion. The more context
sensitivity we have, the more explaining we have to do, and no amount of
explanation might be enough.

My strong preference is to limit context sensitivity or completely
eliminate it, but in the spirit of reconciliation I am also willing to go
with majority :-)

By the way, I did not understand what PNAME_LN and PNAME_NS are. I guessed
that the latter is the foo:bar thingie, but what is LN?

2. PREFIX.
I do not like the syntax PREFIX(...), since it suggests that this is a
fact-formula. However, I am ok with it as a directive (with the same syntax
as you suggest) in the preamble of the document, along with Import and
whatever else we'll end up having there. 

3. Regarding your response to Hassan suggesting &quot; instead of \", I do
not understand your reasoning. You were so gang-ho on brevity and now
suddenly 6 characters instead of two?

If you want to use entities, like &quot;, then why not use them
throughout? That is, instead of rif:iri use &rif;iri, and we are done away
with context-sensitive curies and all that. (This is what I was proposing
from the very beginning except that I was suggesting to use : instead of
&...;.)


	--michael  

> Sorry, this might be unconvenient, but due to an urgent meeting whch I 
> cannot shift, I have to pass on tomorrow's telephone conference.
> 
> So, in order not to hamper progress for DTB, I suggested several options 
> to vote over concerning the points in my mail at [1].
> 
> http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0194.html
> 
> 1) CURIEs: As for 1) there were extensive discussions on the 
> mailinglists, it seems that [2] is kind of a minimalistic proposal 
> whereas [3] is richer. I haven't seen a grammar for [2] yet, so let me 
> put both options on the table again.
> 
> a), cf. [3]
> 
>    ANGLEBRACKIRI     ::= '<' IRIRef '>'
> 
>    STRING            ::= '"' ANYSTRINGWITHOUTQUOTES '"'
> 
>    CURIE                ::=  PNAME_LN | PNAME_NS
> 
>    Const             ::= ANGLEBRACKIRI
>                        | CURIE
>                        | STRING^^ANGLEBRACKIRI
>                        | STRING^^CURIE
> 
> b), cf. [2]
> 
>    ANGLEBRACKIRI     ::= '<' IRIRef '>'
> 
>    STRING            ::= '"' ANYSTRINGWITHOUTQUOTES '"'
> 
>    CURIE                ::=  PNAME_LN | PNAME_NS
> 
>    Const             ::=  CURIE
>                        |  STRING^^ANGLEBRACKIRI
>                        |  STRING^^CURIE
> 
> 
> Comparison between a) and b): The only difference is that b) doesn't 
> allow ANGLEBRACKIRIs as Consts, thus making it N3 incompatible, but 
> well. Both are context-sensitive. There were some other discussions 
> introducing some form of "aliasing" [2,4], but since I didn't see a 
> grammar for this and thus it is unclear whether these would introduce 
> ambiguity,  I suggest to keep it out.
> 
> I suggest to vote between these two, my own vote is for a), though I am 
> willing to obey a majority vote for b). I personally would be unhappy 
> with N3 incompatibility [5,6] when voted for b), since none of the 
> arguments given so far were technical in the sense of that there would 
> be any problem with the grammar for a). For an additional argument, see 
> also 4) below.
> 
> 2) FULL URIs for RIF (see also [7])
> 
>  From the original proposals, the following 2 seem to have "survived" 
> the discussions so far:
> 
> a) define own prefixes (separate for functions and predicates):
> 
>   http://www.w3.org/2007/rif-builtin-predicates#numeric-equal
> 
>   http://www.w3.org/2007/rif-builtin-functions#concat
> 
> c) reuse XPath/Xquery fn: prefix (problem: not prefix defined for op: we 
> still would need to invent one):
> 
>   http://www.w3.org/2005/xpath-??????#numeric-equal
> 
>   http://www.w3.org/2005/xpath-functions#concat
> 
> I personally prefer a) and suggest to
> 
> PROPOSE: We define own namespace prefixes
>    PREFIX("pred", "http://www.w3.org/2007/rif-builtin-predicates#").
>    PREFIX("func", "http://www.w3.org/2007/rif-builtin-functions#").
> for RIF builtin functions and predicates
> 
> 
> 3) The handling of errors seems not to be anything we need to discuss 
> over again.
> 
> 4) Additionally, I suggest to introduce:
> 
>    PREFIXDef         ::= ' PREFIX(' PNAME_LN , STRING ') .'
> 
> for the prefix definition in the presentation syntax.
> Whether this expands to Qnames or entitties in the actual XMLificaiton 
> is a separate issues [8,9] and not important for stabilitzing DTB, it 
> seems. In doubt, I am with Michael here [9] and suggest that in a 
> translator to XML PREFIXDef translates to an ENTITY definition... but 
> that's an implementation detail anyways, one could likewise simply 
> expand all CURIEs in the XML.... The only problem with that is that if 
> you want to translate *BACK* to presentation syntax again, you will end 
> up with something ugly, if we go for option b) on 1) above.
> 
> 
> Axel
> 
> 
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0194.html
> 
> [2] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0015.html
> 
> [3] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0203.html
> 
> [4] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0019.html
> 
> [5] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0005.html
> 
> [6] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0008.html
> 
> [7] http://lists.w3.org/Archives/Public/public-rif-wg/2008Apr/0196.html
> 
> [8] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0011.html
>      and following thread.
> 
> [9] http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0027.html
> 
>

Received on Monday, 5 May 2008 17:09:20 UTC