<rifbot> Created ACTION-392 -
Set up wbs for f2f9 on friday [on Sandro Hawke - due
2007-12-11].

<josb> issue 42: Conceptually
a text constant is a pair of a unicode string and a language
tag.

<josb> Currently we handle
this by means of a rif:text datatype. By virtue of the current definition of
a datatype that means it needs a simple lexical space which is currently
described as "string@lang". However, in the XML
representation we will use the xml:lang attribute to carry the language code and
the string will be conveyed in the element content. So the "string@lang" lexical
form is not explicitly part of the XML representation and a RIF processor,
working from XML, would not be expected to explicitly materialize the
"string@lang" lexical form at any stage. It is unclear whether
this is a problem, or a possible confusion that needs to be explained further
or a non-issue. We are raising it as an issue to record that we have thought about it and may need to examine it
further in the future but it is not something we currently regard as a barrier to
at least the next working draft.

No comments of Sandro regarding rif:text
issue

<sandro> which is to say --
I'm not really happy with this solution -- just using the
mapping table -- but I don't see any serious harm from it, so I
wont object.

<ChrisW> PROPOSED: Resolve
Issue 42 such that the relationship between the xml syntax
treatment of constants and the presentation treatment of
constants is specified in the syntax mapping table

sandro: I think the issue should
be closed as Chris proposed

<sandro> -0: I wont
object

<sandro> (abstain)

<DaveReynolds> (abstain)

<josb> (abstain)

No other objections

<ChrisW> RESOLVED: Resolve
Issue 42 such that the relationship between the xml syntax
treatment of constants and the presentation treatment of
constants is specified in the syntax mapping table

<AxelPolleres> I was offline the last few days, but I also feel unease with it!

josb I would object on that. We need syntactic distinction between builtins and other predicates!

AxelPolleres We need distinguish them syntactically.

<sandro> +1 Axel, a builtin should be part of a dialect, syntactically.

<AxelPolleres> ... and a dialect should also define under which binding patterns they are usable.

<PaulaP> +1 for built-ins as part of a dialect

csma I would expect people to react to the emails concerning a specific subject

josb They say (csma) that should be a fixed list of builtins but I'm in favor of an open
list

<IgorMozetic> +1 for josb: i.e. having an open ended list of builtins

<AxelPolleres> the list IS extensible by dialect extensibility... why would we want two extensibility mechanisms?!?

<csma> May I suggest that we use two different names: builtin for what is fixed and belongs to a dialect

<csma> and eg external call for what is open and free

csma I'm in favor of an open list of builtins
... The dialect should also have a fixed list of builtins part of it.

<PaulaP> +1 for csma's point

<sandro> +1 csma: fixed list of bultins, open list of external calls

<sandro> +1 Axel: it's important for a receiver to know whether a given function is expected to be built-in or not.

csma A specific dialect has a specific list of builtins which are external calls necessary to be implemented
... but out of that there might be other external calls

MichaelKifer I propose an action to JosB or AxelPolleres to clarify addressing of builtins

<Harold> Where the IRI of a 'builtin' points (to a RIF dialect or to some external library), would show what kind of 'builtin' it is.

<AxelPolleres> just to make clear: I do NOT want 2 different forms of built-ins/external function calls.
I was rather suggesting that only the ones defined in the dialect should be allowed. If you need more, extend the dialect.

<Harold> With IRIs as the distinguishing element, we would not need other syntactic means.

Recall the MichaelKifer proposal: an action to clarify addressing of builtins

<AxelPolleres> As long as this is not subject to interchange, all is fine :-)

<sandro> The question is: do app-specific parts of a system need to be part of a new dialect?

<csma> If you do not accept that some elements required for an interchange will be agreed on out of band, you will have very little actual
interchanges

<sandro> +1 Axel: app-specific parts should be part of a dialect definition, if you want to interchange them.

<sandro> The question, csma, is whether that agreement is equal to agreeing to some dialect.

ChrisW We should allow people to extends their list of builtins

<sandro> +1 Chris: We all agree that folks should be able to extend the list of builtins,
we just disagree about whether to call that new agreement is called a 'dialect'.

csma We need that two parties can extend the fixed list of builtins

<sandro> -1 csma: The label 'dialect' matters because it forbids out of band agreement. [ I
don't see that at all. ]

<sandro> Chris: (1) agrrement to have call some-uri

<csma> To Sandro: that's what I have been saying all the time. That's why I think that I
disagree with Axel

<sandro> Chris: (2) the list of external calls specified by a dialect are "the builtins"

<sandro> Chris: (3) you should be allowed to extend that list among consenting parties
-- BUT we're not agreed at the moment about whether to call that extension a new dialect.

<Harold> Since different RIF dialects D1, ..., Dn should be allowed to share a given set of
builtins B, D1, ..., Dn should point to B a la D1->B, ..., Dn->B, rather than 'adding' B into D1, ..., Dn as new
dialects a la D1+B, ..., Dn+B.

<AxelPolleres> but then we agree on a dialect? right? and whether we decide to writye down
the dialect and publish it is our own business.

<sandro> Chris: (4) We're also not agreed about whether we need a formal mechanism about
extending the list of builtins.

ChrisW We can close this issue

<josb> issue 40: At the moment the WG has agreed to support "builtins", in particular
those defined for supported XS datatypes, however the syntactic and semantic treatment of builtins has not been made clear.
One issue is how they will relate to functions in the syntax (e.g. are builtins just logic functions?).
Another issue is whether builtins will be sensitive to "order" as they are in query languages and
production rules; in these cases, the order is understood to be required to "bind" variables before the builtin is called.