IRC log of rif on 2009-01-15

Timestamps are in UTC.

00:00:23 [sandro]

Changhai: in foo # X X is a type, not a collection....

00:04:28 [sandro]

Sandro: Is this work necessary to PRD?

00:04:56 [sandro]

Paul: Yes, althoug maybe we need even better access to XML (than frames allow).

00:06:15 [sandro]

Gary:My proposal is pretty much how our product works (jaxb style -- flash conversion). The XPath peek & poke approach would be something we'd have to hide in translation.

00:07:15 [sandro]

Gary: I'm not wedded to using the schema to construct names. JAXB just uses the local names.

00:07:18 [ChrisW]

ChrisW has joined #rif

00:08:01 [sandro]

sandro: If RIF doesn't do this, you'll need to do a non-standard version of this?

00:08:10 [sandro]

csma, paul, gary: yes.

00:08:51 [sandro]

paul: PRR dodges this issue.

00:09:09 [sandro]

Adrian: reaction-ruleml has a way to do something like this.

00:10:12 [sandro]

csma: You could re-use this work with UML instead of Schema.

00:11:18 [sandro]

"Using RIF with XML and Object-Oriented Data" ?

00:11:34 [sandro]

csma: I think we'll be content with just "Using RIF with XML"

00:13:55 [AdrianP]

additionally in a query /constraint expression language you could explicitly define closures over object relations which can not be done directly in FOL

00:14:58 [sandro]

csma: If you want to *really* retrieve a class and it's subclasses, you need to do it several different ways, given XMLS.

00:15:45 [PaulVincent]

Way ahead suggestion: have 1 or more DSLs evaluate these approaches for embedding XML-enabled PRD in their docs, eg MISMO?

00:19:58 [sandro]

PROPOSED: Create a new document, something like "Using RIF with OWL", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

00:20:15 [sandro]

gah. typo of "OWL" for "XML" :-)

00:20:17 [StellaMitchell]

StellaMitchell has joined #rif

00:20:39 [sandro]

PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

00:20:42 [Harold]

zakim, who is here?

00:20:42 [Zakim]

On the phone I see RIF_Meeting_Room, Hassan_Ait-Kaci (muted)

00:20:43 [Zakim]

RIF_Meeting_Room has Christian, Gary, Harold, Adrian, Jos, Paul, Micheal_Kifer, Changhai, Sandro

00:20:46 [Zakim]

On IRC I see StellaMitchell, ChrisW, Hassan, csma, PaulVincent, josb, GaryHallmark, Michael_Kifer, cke, Harold, RRSAgent, AdrianP, sandro, mdean, trackbot, Zakim

00:21:53 [sandro]

csma: it's important that whatever we do relies on features in current engines. and be extensible for doing stuff like more of XPath in the future.

00:21:55 [Zakim]

+Stella_Mitchell

00:22:13 [sandro]

PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF.

00:23:00 [ChrisW]

i haven't been part of the discussion

00:23:12 [ChrisW]

but i would strongly object to starting new work

00:23:25 [sandro]

PROPOSED: Create a new document, something like "Using RIF with XML", addressing ISSUE-37 and ISSUE-38, in the space of Gary and Christian's proposals, for RIF rules to use XML data wth and without a schema. What it specifies should work with Core, BLD, and PRD, and is important to the success of RIF. This technology is not just for use of XML data, but for using XML Schemas to communicate data models.

00:24:04 [sandro]

ChrisW, Gary, Paul, and the ILOG (and IBM company) folks say they have to have this for PRD to be useful.

00:24:14 [sandro]

s/,/-/

00:24:59 [ChrisW]

I've heard the same argument for a lot of things in RIF

00:25:49 [csma]

The alternative to starting a new doc is including it in PRD.

00:26:22 [csma]

since this is useful to other dialects as well, better put it in a separate doc instead of a PRD section

00:26:58 [ChrisW]

finish the work on PRD first, then consider this for a note. But only when the existing drafts are at LC

00:27:14 [ChrisW]

no new work

00:27:18 [ChrisW]

i repeat, no new work

00:27:19 [sandro]

sandro: I think the risk of new-work is somewhat reduced buy having it be an independent document.

00:27:40 [Harold]

Also look into related work such as Schema-Aware Queries and Stylesheets (http://www.stylusstudio.com/schema_aware.html) and Schema-aware processing with XSLT (http://www.ibm.com/developerworks/xml/library/x-schemaxslt.html).

00:27:56 [ChrisW]

this has too many other implications

00:28:05 [ChrisW]

i will object

00:30:53 [sandro]

sandro: We could publish a VERY DRAFT WD on this, which is just the cut and paste of Gary's and CSMA's proposals, to [as csma says] let people know this kind of work is doable, so they know PRD might be useful.

00:31:41 [sandro]

gary: In our product, we tried an xpath thing, but ended up putting the whole document in, because it worked better for what customers wanted.

00:33:08 [sandro]

csma: I want to borrow XPath.

00:34:42 [sandro]

gary: RIF CL is already a query language, so it's kind of painful to combine it with another, like XPath.

00:34:44 [sandro]

csma: true.

00:34:52 [sandro]

BREAK until 17:00

00:35:16 [Zakim]

-Stella_Mitchell

00:37:31 [Zakim]

-Hassan_Ait-Kaci

01:05:02 [sandro]

scribenick: Michael_Kifer

01:05:12 [sandro]

restarting

01:06:41 [Michael_Kifer]

CSMA: issue: forall is different in BLD and PRD

01:06:57 [sandro]

csma: Forall means something different in PRD from Core. It means "for each value that you can bind" ... which has the same effect. But PRD also needs the real forall...?

01:10:28 [sandro]

sandro: (listening to Changhai's example) You want an aggregate. if forall x...

01:10:43 [Zakim]

+Stella_Mitchell

01:13:41 [sandro]

sandro: so this, in practice, needs closed world assumption,

01:13:45 [sandro]

jos: or negation

01:14:46 [sandro]

gary: we have this now in PRD via "not exists".

01:16:05 [Michael_Kifer]

the issue seems to be "forall" outside of the rule vs. "forall" in the rule body

01:16:27 [sandro]

paul: "if at least 3..."

01:17:11 [sandro]

csma: So the forall inside the rule and outside the rule are really the same?

01:17:20 [sandro]

Michael_Kifer: Yes

01:17:25 [sandro]

Jos: Yes

01:22:05 [Michael_Kifer]

decided that this is a non-issue

01:22:06 [Harold]

BLD's Forall can work over infinite sets such as {0, s(0), s(s(0)), . . .}:

01:22:11 [Harold]

Forall ?N ( nat(s(?N)) :- nat(?N) )

01:22:40 [josb]

Next topic, please!

01:23:01 [sandro]

csma: on board:

01:23:01 [sandro]

forall ?x ( ?x # Car)

01:23:01 [sandro]

if forall ?y ( ?y # Door )

01:23:01 [sandro]

?x[door->?y] and ?y[color->red]

01:23:01 [sandro]

then Paint It Blue

01:23:23 [sandro]

(all agree, the two forall as "the same", and can use the same syntax.)

01:23:52 [sandro]

(if the language were to support forall inside a condition.)

01:23:54 [Michael_Kifer]

Next: issue 39, RIF should support import or inclusion of rulesets

01:23:56 [josb]

http://www.w3.org/2005/rules/wg/track/issues/39

01:27:10 [Michael_Kifer]

import is in core already. CSMA: might cause conflicts in conflict resolution strategies

01:29:06 [sandro]

agreed: if PRD imports with a different Res.Strat. it should ... say what happens. (one rules, or error, or something.)

01:29:20 [Michael_Kifer]

proposed: close issue 39

01:29:33 [sandro]

PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time.

01:29:44 [Michael_Kifer]

because core already has import

01:29:46 [josb]

+1

01:30:12 [Harold]

+1

01:30:43 [sandro]

Michael_Kifer: i'd like includes would be including rules, not whole documents....

01:31:05 [sandro]

PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean).

01:31:12 [sandro]

+1

01:31:17 [josb]

++1

01:31:27 [Michael_Kifer]

+1

01:31:28 [josb]

+++1

01:36:42 [sandro]

Sandro: it sounds like Core:imports wont be a pain to implement in PRD, even though it doesn't do all the fance stuff some PRD engines really want in imports.

01:38:00 [sandro]

csma: Import is specified in the dumb way -- without juggling priorities -- so it's not very useful in PRD.

01:38:45 [Zakim]

+Hassan_Ait-Kaci

01:39:11 [sandro]

gary: Yeah, someday we'll need to specify complex ways to do import in PRD.

01:40:03 [Michael_Kifer]

current import mechanism is too primitive for PRD. Need to expand it in the future for PRD

01:41:10 [sandro]

RESOLVED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). It ends up in PRD, where it's not ideal, but not really harmful. Some PRD may do a more sophisticated import at some point.

01:41:13 [Michael_Kifer]

csma: the current import mechanism in core is acceptable, but it is not very interesting for prd.

01:41:37 [sandro]

s/RESOLVED/PROPOSED/

01:42:24 [sandro]

PROPOSED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point.

01:42:35 [sandro]

+1

01:42:57 [sandro]

Harold: when you find the better imports, propose it to the rest of RIF!

01:43:08 [Harold]

+1

01:43:15 [josb]

+1

01:43:16 [Michael_Kifer]

+1

01:43:16 [AdrianP]

+1

01:43:17 [GaryHallmark]

+1

01:43:26 [PaulVincent]

+1

01:43:55 [sandro]

RESOLVED: Close issue-39, saying ruleset-imports is in Core, and we're not going to define an "includes" at this time (in part because we don't know what it might mean). 'Imports' ends up in PRD, where it's not ideal, but not really harmful. Some version of PRD may do a more sophisticated import at some point.

01:44:04 [sandro]

RRSAgent, pointer?

01:44:04 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T01-44-04

01:45:04 [cke]

cke has joined #rif

01:47:00 [cke]

cke has joined #rif

01:50:45 [sandro]

Sandro: let's put "filters" ("such that" expressions) as syntactic sugar into Core.

01:51:02 [sandro]

MK: bounded quantifies.

01:51:03 [cke]

good idea

01:51:08 [josb]

Let's not. The syntax is already complicated enough

01:52:29 [sandro]

Sandro: So, if we have to do a LC2 -- then we can talk about this.

01:54:19 [sandro]

ISSUE: Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway)

01:54:32 [trackbot]

Created ISSUE-91 - Should we put bounded quantifiers into Core? (forall x such than x # C ...) (esp if we need an LC2 for BLD anyway) ; please complete additional details at http://www.w3.org/2005/rules/wg/track/issues/91/edit .

01:58:03 [sandro]

MK: bounded quants are not very useful in BLD, and the re-writing is a little tricky.

01:58:52 [sandro]

csma: Many rules are written with BQs, and people don't want to discard that optimization. Also, you need BQs for any else-clause.

01:59:28 [Zakim]

-Stella_Mitchell

01:59:41 [Michael_Kifer]

Forall ?X in C (h :- body) is Forall ?X (h :- body and C).

02:01:50 [sandro]

ADJOURN - 1 minute late

02:02:42 [josb]

http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=higgins+portland&sll=37.0625,-95.677068&sspn=34.945679,58.886719&ie=UTF8&ll=45.51541,-122.680957&spn=0.001887,0.003594&z=18&iwloc=A

02:04:11 [josb]

http://maps.google.com/maps?f=d&source=s_d&saddr=SW+5th+Ave&daddr=1239+SW+Broadway,+Portland,+OR+97205+(Higgins+Restaurant)&hl=en&geocode=FYaBtgId7w6w-A%3B&mra=cc&dirflg=w&sll=45.515407,-122.680786&sspn=0.001887,0.003594&ie=UTF8&z=18

02:06:48 [josb]

coffee: http://maps.google.com/maps?f=d&source=s_d&saddr=45.515221,-122.679648&daddr=128+SW+3rd+Ave,+Portland,+OR+97204+(Stumptown+Coffee+Roasters)&hl=en&geocode=&mra=mi&mrsp=0&sz=15&dirflg=w&sll=45.518045,-122.676859&sspn=0.015095,0.028753&ie=UTF8&z=15

02:08:32 [Zakim]

-Hassan_Ait-Kaci

02:09:31 [Zakim]

-RIF_Meeting_Room

02:09:32 [sandro]

zakim, who is on the phone?

02:09:33 [Zakim]

SW_RIF(F2F12)11:00AM has ended

02:09:35 [Zakim]

Attendees were Mike_Dean, Hassan_Ait-Kaci, Christian, Gary, Harold, Adrian, Jos, Paul, Micheal_Kifer, Changhai, Sandro, Stella, +44.145.441.aaaa, DaveReynolds, +1.212.781.aabb,

02:09:39 [Zakim]

... LeoraMorgenstern, StellaMitchell, ChrisW, Stella_Mitchell

02:09:41 [Zakim]

apparently SW_RIF(F2F12)11:00AM has ended, sandro

02:09:42 [Zakim]

On IRC I see cke, ChrisW, Hassan, csma, josb, GaryHallmark, Michael_Kifer, Harold, RRSAgent, sandro, mdean, trackbot, Zakim

02:15:06 [sandro]

rrsagent, make record public

02:15:11 [sandro]

rrsagent, make minutes

02:15:11 [RRSAgent]

I have made the request to generate http://www.w3.org/2009/01/15-rif-minutes.html sandro

02:47:49 [sandro]

sandro has joined #rif

02:57:18 [sandro]

sandro has joined #rif

19:04:54 [RRSAgent]

RRSAgent has joined #rif

19:04:54 [RRSAgent]

logging to http://www.w3.org/2009/01/15-rif-irc

19:05:03 [sandro]

RRSAgent, make minutes

19:05:03 [RRSAgent]

I have made the request to generate http://www.w3.org/2009/01/15-rif-minutes.html sandro

19:05:42 [sandro]

pointer?

19:05:47 [sandro]

RRSAgent, pointer?

19:05:47 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T19-05-47

19:34:25 [sandro]

zakim, who is on the call?

19:34:25 [Zakim]

On the phone I see RIF_Meeting_Room

19:34:34 [sandro]

RESTARTING

19:34:54 [josb]

josb has joined #rif

19:35:58 [sandro]

scribenick: cke

19:36:12 [sandro]

issue-48?

19:36:12 [trackbot]

ISSUE-48 -- Classification constructs in Core [NOT CP] -- OPEN

19:36:12 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/48

19:36:16 [apaschke]

apaschke has joined #rif

19:37:53 [DaveReynolds]

DaveReynolds has joined #rif

19:39:16 [Zakim]

+DaveReynolds

19:39:24 [cke]

Membership means: object # classname, where classname is a name of a class (correction of yesterday)

19:42:27 [sandro]

PROPOSED: Have # and ## in Conditions and Facts in Core.

19:43:12 [DaveReynolds]

-1

19:43:19 [josb]

-1

19:43:25 [GaryHallmark]

+1

19:43:32 [sandro]

+1

19:43:48 [sandro]

DaveReynolds: I have two problems with these

19:44:12 [sandro]

DaveReynolds: I'd like to be able to assert these as well -- the restrictions are awkward.

19:45:00 [sandro]

DaveReynolds: ## is a problem because it's different from rdfs:subClassOf. I didn't object when ## went into BLD like this, because it was said it wouldn't be in core.

19:45:25 [pvincent]

+1 to Dave as subclass tests not that interesting to PR engines...

19:45:40 [sandro]

DaveReynolds: I could live with # in Conditions and Facts in Core. (we already decided this.)

19:46:25 [sandro]

mk: What does PRD do about an rdfs:subClassOf appearing in the head of a rule?

19:47:10 [sandro]

Jos: as we said earlier, there's no interop between PRD and RDFS.

19:49:14 [sandro]

sandro: PRD's notion of classes and RDF's notion of classes will just be independent. Oh well, that's how it is.

19:51:25 [sandro]

PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core.

19:51:46 [sandro]

Jos: Take # out of core because it's redundant with rdf:type

19:52:53 [DaveReynolds]

Jos - could you talk closer to a mike?

19:53:17 [cke]

Jos: agree with Dave that subclass is not the same as in RDFS

19:55:11 [sandro]

Sandro: I'd like # and ## in core, with ## fixed to align with rdfs:subClassOf.

19:55:56 [sandro]

## == subclassof and not equivalent class

19:56:04 [sandro]

PROPOSED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core.

19:56:11 [sandro]

+0

19:56:13 [josb]

0

19:56:17 [cke]

+1

19:56:20 [pvincent]

+1

19:56:21 [apaschke]

+1

19:56:21 [Harold]

+1

19:56:26 [DaveReynolds]

0

19:56:33 [GaryHallmark]

0

19:56:52 [Zakim]

+??P1

19:56:54 [Michael_Kifer]

0

19:57:55 [Zakim]

-??P1

19:58:00 [sandro]

RESOLVED: Close issue-48. membership (#) in Core facts and conditions. subclass (##) not in Core.

19:58:06 [sandro]

RRSAgent, pointer?

19:58:06 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T19-58-06

19:58:41 [sandro]

issue-68?

19:58:41 [trackbot]

ISSUE-68 -- Named argument UNITERM in CORE? -- OPEN

19:58:41 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/68

19:59:45 [sandro]

PROPOSED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD.

19:59:53 [josb]

+1

19:59:56 [DaveReynolds]

+1

20:00:03 [sandro]

+1

20:00:05 [Harold]

0

20:01:55 [sandro]

I'd like to put this on the list of things to take out of BLD.

20:02:26 [pvincent]

+1

20:02:28 [GaryHallmark]

0

20:03:28 [Michael_Kifer]

0

20:03:38 [cke]

0

20:03:38 [sandro]

RESOLVED: close issue-68 with no Named-Argument Uniterms (NAU) in Core or PRD.

20:03:41 [sandro]

RRSAgent, pointer?

20:03:41 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T20-03-41

20:03:49 [sandro]

action: csma remove NAU from PRD

20:03:50 [trackbot]

Created ACTION-691 - Remove NAU from PRD [on Christian de Sainte Marie - due 2009-01-22].

20:04:09 [sandro]

issue-72?

20:04:09 [trackbot]

ISSUE-72 -- Should Core support some approximation to skolem functions? -- OPEN

20:04:09 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/72

20:04:22 [Harold]

http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0245.html

20:04:37 [Harold]

(above link shows CLIPS example with NAU)

20:06:13 [sandro]

PROPOSED: Close issue-72 saying "No". (Nothing like skolem functions in Core.)

20:06:43 [sandro]

DaveReynolds: not happy, but I wouldnt object.

20:08:39 [sandro]

PROPOSED: Close issue-72 saying "No". (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need.

20:09:32 [sandro]

gary: challenges with making it deterministic -- eg two new objects when rule fires twice.

20:09:59 [sandro]

gary: it didn't seem possible to solve in the general PRD case.

20:10:14 [cke]

+0

20:10:19 [sandro]

PROPOSED: Close issue-72 saying "No" (Option D). (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need.

20:10:20 [DaveReynolds]

0

20:10:26 [GaryHallmark]

0

20:10:29 [sandro]

0

20:10:32 [cke]

0

20:10:33 [Harold]

1

20:10:35 [josb]

+1

20:10:39 [pvincent]

+0

20:10:39 [Michael_Kifer]

1

20:10:43 [apaschke]

0

20:10:51 [sandro]

RESOLVED: Close issue-72 saying "No" (Option D). (Nothing like skolem functions in Core.) We regret we were unable to find a good design to address this need.

20:10:55 [sandro]

RRSAgent, pointer?

20:10:55 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T20-10-55

20:11:29 [sandro]

issue-33?

20:11:29 [trackbot]

ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- OPEN

20:11:29 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/33

20:11:34 [apaschke]

with respect to named arguments in PRD, CLIPS has named arguments. Did we check with all the decendants of CLIPS, e.g. ECLiPSe, Haley Eclipse, FuzzyCLIPS, Jess, DR-Device, ...

20:13:00 [sandro]

PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources will be sufficient.

20:13:31 [josb]

+1

20:13:32 [pvincent]

+1

20:13:33 [DaveReynolds]

Harold, Adrian - the CLIPS facts are not NAUs normally, you can pattern match on a subset of the arguments

20:13:46 [sandro]

PROPOSED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using external builtins, will be sufficient.

20:13:55 [sandro]

+1

20:14:01 [cke]

+1

20:14:07 [Michael_Kifer]

1

20:14:09 [DaveReynolds]

+1

20:14:13 [apaschke]

0

20:14:17 [pvincent]

+1

20:14:27 [Harold]

+1

20:14:38 [sandro]

RESOLVED: Close issue-33 with the understand that our mechanisms for accessing RDF and XML data sources, and using externals, will be sufficient.

20:14:41 [GaryHallmark]

+1

20:14:41 [sandro]

RRSAgent, pointer?

20:14:41 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T20-14-41-1

20:15:12 [sandro]

issue-78?

20:15:13 [trackbot]

ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- OPEN

20:15:13 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/78

20:16:24 [josb]

http://www.w3.org/2005/rules/wiki/BLD#Formulas

20:16:48 [sandro]

csma: currently -- BLD externals can be position or na term, or a frame. later (frame) at risk.

20:17:04 [sandro]

csma: issue was raised because I didn;t know what an external frame was.

20:17:48 [sandro]

sandro: example?

20:19:55 [sandro]

sandro: (with help from jos) if you think of frames as a single ternary predicate, external frames are just consulting a single external ternary predicate (not related to normal frames).

20:20:18 [sandro]

csma: any frame can be external

20:20:36 [sandro]

mk: yes. it was just an oversight. #, ##, and = should be external-able.

20:20:56 [sandro]

mk: some kinds of = are builtin.

20:20:56 [DaveReynolds]

The problem is that the current external mechanism doesn't have a way to communicate which external source to consult. Especially for frames this is a problem.

20:21:34 [sandro]

mk: another oversight -- there should be an IRI provided for the external from, to identify the source. we don't have any place to give that.

20:21:44 [sandro]

csma: that's in the defn't of the external.

20:22:59 [sandro]

mk: when you get an RIF document, with an external frame, there should be some IRI identifying which source for external frames.

20:25:03 [sandro]

sandro: don't have anything external except for predicates and functions. If you want your own #, then give it your own URI name.

20:26:35 [sandro]

PROPOSED: The only Externals in BLD will be Predicates and Functions. No external frames, no external equality, etc.

20:27:07 [sandro]

PROPOSED: The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc.

20:27:11 [josb]

+1

20:27:18 [DaveReynolds]

+1

20:27:32 [sandro]

PROPOSED: Close issue-78. The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc.

20:27:41 [cke]

+1

20:27:46 [Harold]

0

20:27:47 [sandro]

+1

20:27:58 [Michael_Kifer]

0

20:28:26 [sandro]

RESOLVED: Close issue-78. The only Externals in BLD (and Core, and PRD) will be Predicates and Functions. No external frames, no external equality, etc.

20:28:29 [sandro]

RRSAgent, pointer?

20:28:29 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T20-28-29

20:29:28 [sandro]

BREAK FOR LUNCH

20:29:34 [sandro]

issue-48?

20:29:34 [trackbot]

ISSUE-48 -- Classification constructs in Core [NOT CP] -- CLOSED

20:29:34 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/48

20:29:40 [sandro]

issue-68?

20:29:40 [trackbot]

ISSUE-68 -- Named argument UNITERM in CORE? -- CLOSED

20:29:40 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/68

20:29:44 [Zakim]

-DaveReynolds

20:29:52 [sandro]

issue-72?

20:29:52 [trackbot]

ISSUE-72 -- Should Core support some approximation to skolem functions? -- CLOSED

20:29:52 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/72

20:29:56 [sandro]

issue-33?

20:29:56 [trackbot]

ISSUE-33 -- Specification of data sources in RIF [NOT CP] -- CLOSED

20:29:56 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/33

20:30:00 [sandro]

issue-78?

20:30:01 [trackbot]

ISSUE-78 -- Which to make external: ATOMIC, ATOM, or ATOM|FRAME -- CLOSED

20:30:04 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/78

20:30:21 [cke]

We restart at 13:30.

20:32:10 [sandro]

issue-46?

20:32:10 [trackbot]

ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN

20:32:10 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/46

21:37:22 [josb]

josb has joined #rif

21:38:01 [Harold]

http://www.econ.kuleuven.be/eng/fetew/medewerker/Userpage.aspx?PID=271

21:41:51 [chke]

chke has joined #rif

21:41:56 [sandro]

issue-69?

21:41:56 [trackbot]

ISSUE-69 -- Should there be a Core schema incldued in BLD and PRD schemata? -- OPEN

21:41:56 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/69

21:42:17 [sandro]

scribenick: gary

21:42:35 [Zakim]

+DaveReynolds

21:42:38 [Zakim]

-RIF_Meeting_Room

21:42:39 [Zakim]

+RIF_Meeting_Room

21:43:24 [GaryHallmark]

harold: specialize bld schema to arrive at core schema

21:43:37 [GaryHallmark]

... should look at how to inherit core into bld

21:44:07 [sandro]

harold: easiest thing to do is copy BLD schema for Core, then edit it to constrain it more. then maybe look at where we can use include.

21:44:17 [GaryHallmark]

... inherit means xml include

21:44:34 [AdrianP]

AdrianP has joined #rif

21:45:10 [GaryHallmark]

sandro: include is just an editorial change

21:46:34 [GaryHallmark]

sandro: who will do the modularization exercise?

21:46:59 [GaryHallmark]

harold: will help changhai

21:47:08 [sandro]

ACTION: changhai to draft modularized Core and PRD schema, coordinating with Harold on BLD Schema

21:47:08 [trackbot]

Created ACTION-692 - Draft modularized Core and PRD schema, coordinating with Harold on BLD Schema [on Changhai Ke - due 2009-01-22].

21:48:50 [Harold]

In http://www.w3.org/2005/rules/wiki/BLD#Rule_Language we have <xs:include schemaLocation="BLDCond.xsd"/>.

21:49:17 [GaryHallmark]

changhai: work toward a core schema and BLD and PRD schemas that include the core schema

21:49:24 [DaveReynolds]

Harold - is the Core schema online or on the wiki somewhere?

21:49:47 [Harold]

A Core schema doesn't exist yet.

21:49:53 [sandro]

PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692.

21:49:59 [DaveReynolds]

Sorry misheard, your audio is very quiet

21:50:09 [csma]

zakim, who is on the phone?

21:50:09 [Zakim]

On the phone I see RIF_Meeting_Room, DaveReynolds

21:50:35 [DaveReynolds]

:-)

21:50:44 [sandro]

proooooojeeeeeect

21:51:08 [sandro]

PROPOSED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692.

21:51:25 [sandro]

+1

21:51:36 [AdrianP]

+1

21:51:37 [chke]

+1

21:51:38 [josb]

+1

21:51:39 [DaveReynolds]

+1

21:52:00 [Harold]

+1

21:52:03 [Michael_Kifer]

1

21:52:05 [GaryHallmark]

+1

21:52:10 [sandro]

RESOLVED: Close issue-69; there will be a Core schema, included in BLD and PRD schemas. see ACTION-692.

21:52:29 [sandro]

rrsagent, pointer?

21:52:29 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T21-52-29

21:54:24 [sandro]

issue-46?

21:54:24 [trackbot]

ISSUE-46 -- Modules in RIF [NOT CP] -- OPEN

21:54:24 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/46

21:55:53 [sandro]

PROPOSED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it.

21:56:09 [chke]

+1

21:56:20 [sandro]

+1

21:56:20 [DaveReynolds]

+1

21:56:26 [AdrianP]

+1

21:56:27 [Harold]

+1

21:56:33 [GaryHallmark]

+1

21:56:38 [josb]

+1

21:56:40 [sandro]

RESOLVED: Close issue-46; no decision to make at this time. If someone produces a proposal for modules, we may consider it.

21:56:45 [sandro]

RRSAgent, pointer?

21:56:45 [RRSAgent]

See http://www.w3.org/2009/01/15-rif-irc#T21-56-45

21:57:43 [sandro]

issue-50?

21:57:43 [trackbot]

ISSUE-50 -- Semantic metadata -- OPEN

21:57:43 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/50

21:58:04 [Zakim]

+[IPcaller]

21:58:41 [sandro]

issue-80?

21:58:41 [trackbot]

ISSUE-80 -- Shoudl we extend DTB to include more general builtins -- OPEN

21:58:41 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/80

21:59:41 [sandro]

Axel: unfort. my keyboard is broken. so I cannot type on IRC. :-(

22:00:08 [Zakim]

-[IPcaller]

22:01:02 [sandro]

<csma> RESOLVED: add isLiteralOfType and isLiteralNotOfType (Changing guards to return true only for literals that are/are not of the type, false for non-literals) and remove specific type-named guards (e.g. isInteger, isNotInteger). Closing ISSUE-79 and the membership/non-membership part of ISSUE-80.

22:04:31 [Zakim]

+??P4

22:04:51 [sandro]

Gary: can we just have a "type" for everything that's not a literal?

22:06:05 [josb]

Sandro, Gary, negation would become a problem, i.e., isNotObject is a problem; isObject would not be a problem, I think

22:07:15 [josb]

isNotObject=isLiteral, so should actually not be a problem

22:07:19 [sandro]

jos: maybe yes we could do "isObject".

22:07:35 [Zakim]

-??P4

22:07:52 [AdrianP]

something like isType(?X, Object)

22:08:08 [AdrianP]

isType(?X, Integer)

22:08:49 [sandro]

Jos: "object" in owl is owl:Thiing

22:09:37 [sandro]

sandro: obviously isLiteralofTtyype, etc, are clumsy and something more elegant would be great.

22:10:05 [GaryHallmark]

sandro: what about isObject, isLiteral

22:10:30 [GaryHallmark]

jos: isLiteral

22:10:39 [DaveReynolds]

We put the isLiteral part in notType as part of resolving the negative guards, the isLiteral part of ofType is just there for symmetry

22:11:14 [GaryHallmark]

sandro: need to cover unknown datatypes

22:11:46 [GaryHallmark]

dave: needed neg guards for owl RL

22:12:31 [josb]

isLiteralNotInteger(x) :- isLiteral and (isDouble and isFloat ....)

22:12:36 [josb]

isLiteralNotInteger(x) :- isLiteral and (isDouble or isFloat ....)

22:12:46 [GaryHallmark]

jos: instead of neg guards, enumerate, e.g. isNotInt == isDouble or isString or ...

22:13:19 [GaryHallmark]

... can't cover because value spaces not disjoint

22:14:27 [sandro]

issue-81?

22:14:27 [trackbot]

ISSUE-81 -- Support for additional OWL-RL datatype -- OPEN

22:14:27 [trackbot]

http://www.w3.org/2005/rules/wg/track/issues/81

22:15:53 [GaryHallmark]

sandro: separate owl: and xsd: types

22:16:59 [GaryHallmark]

... rationale for xsd: is completeness. for owl:, ability to use RIF to implement owl RL

22:17:50 [GaryHallmark]

jos: possible issue with lex spaces not disjoint

22:18:57 [sandro]

DaveReynolds: problem with binary types is: what builtins should we have? some work there?

22:19:57 [josb]

the set of additional XPath functions is small: http://www.w3.org/TR/xpath-functions/

22:20:51 [DaveReynolds]

If you are talking about numerics now then see http://lists.w3.org/Archives/Public/public-rif-wg/2009Jan/0017.html

22:21:06 [sandro]

sandro: I expect users are going to want promotion

22:26:17 [josb]

what if we do type promotion, even with non-disjoint value spaces?

22:28:01 [GaryHallmark]

dave: if value space is not disjoint, then you can't dispatch on the type of the inputs to builtins (like numeric-add) so it makes type promotion tricky (roughly paraphrased by scribe)

22:30:29 [DaveReynolds]

dave: (adding to Gary's paraphrase) further in XPath you would promote to double, whereas for the OWL approach you would promote to BigDecimal and so do arbitrary precision arithmetic a lot of the time

22:32:21 [LeoraMorgenstern]

LeoraMorgenstern has joined #rif

22:32:29 [GaryHallmark]

jos: will try to convince owl that disjointness is a good thing

22:32:54 [Zakim]

+LeoraMorgenstern

22:33:02 [GaryHallmark]

dave: owl has no builtins, so they don't have our motivation

22:33:26 [GaryHallmark]

sandro: may need formal objection

22:33:29 [josb]

our main argument we can give OWL is extensibility

22:38:06 [sandro]

sandro: XSD is so broken. :-) hexBinary and base64Binary both have identically described value spaces, but they are also defined as being disjoint.

22:38:54 [josb]

http://www.w3.org/TR/xmlschema11-2/#order

22:39:03 [josb]

"For purposes of this specification, the value spaces of primitive datatypes are disjoint, even in cases where the abstractions they represent might be thought of as having values in common."

22:39:29 [josb]

Sandro, I agree; the spec is broken

22:40:31 [josb]

also: http://www.w3.org/TR/xmlschema-2/#equal

22:40:38 [josb]

"# the ·value space·s of all ·primitive· datatypes are disjoint (they do not share any values) "

22:43:54 [StellaMitchell]

StellaMitchell has joined #rif

22:44:03 [sandro]

Changhai: use case for xsd:hasBinary is including an encrypted password.

22:44:11 [sandro]

s/has/hex/

22:45:27 [chke]

base64binary looks like to be the way to convert binary information into printable characters. This is required for storing passwords, for example.

22:45:27 [sandro]

PROPOSED: Include all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately.

22:45:47 [sandro]

PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately.

22:45:55 [DaveReynolds]

Does that include the string subtypes?

22:46:15 [sandro]

PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately.

22:47:15 [sandro]

PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces -- we'll push for OWL to change. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately.

22:47:27 [DaveReynolds]

Does that include the string subtypes?

22:47:51 [sandro]

yes (as written)

22:47:52 [GaryHallmark]

subtypes are not disjoint

22:48:20 [sandro]

PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately.

22:48:48 [DaveReynolds]

I would vote -0.1 against include the string subtypes - they are pointless

22:49:20 [sandro]

PROPOSED: Include in RIF Core all the xsd:* datatypes used by OWL RL and listed in issue-81. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately.

22:53:00 [sandro]

PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core.

22:53:02 [GaryHallmark]

dave: anyURI is only useful string subtype

22:53:24 [sandro]

jos: anyURI is NOT a subtype of string -- it's a separate data type.

22:53:26 [GaryHallmark]

jos: actually, anyURI is primitive

22:54:15 [sandro]

PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core.

22:54:31 [GaryHallmark]

note that xsd:anyURI is a datatype whereas rif:iri is only a symbol space

22:54:50 [sandro]

PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. The owl:* types will be decided separately. Value spaces of Binaries will be decided separately.

22:55:57 [sandro]

ACTION: josb to push back on OWL-WG about disjoint value spaces

22:55:58 [trackbot]

Created ACTION-693 - Push back on OWL-WG about disjoint value spaces [on Jos de Bruijn - due 2009-01-22].

22:57:14 [sandro]

PROPOSED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. [The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. When those are decided, it will close issue-81]

22:57:38 [josb]

+1

22:57:38 [sandro]

+1

22:57:40 [DaveReynolds]

+1

22:57:46 [chke]

+1

22:57:49 [Harold]

+1

22:57:53 [LeoraMorgenstern]

0

22:57:54 [AdrianP]

+1

22:57:55 [GaryHallmark]

+1

22:57:58 [Michael_Kifer]

1

22:58:06 [pvincent]

=0

22:58:06 [sandro]

RESOLVED: Add xsd:nonNegativeInteger, xsd:anyURI, xsd:hexBinary, xsd:base64Binary to RIF Core. In RIF, the xsd numeric types will have disjoint value spaces (as in XSD1.1, unlike current OWL 2 drafts)-- we'll push for OWL to change and assume they will. [The owl:* types will be decided separately. Value spaces of Binaries will be decided separately. When those are decided, it will close issue-81]

22:58:40 [sandro]

clarifying -- we're NOT adding the listed subtypes of String

22:59:00 [DaveReynolds]

I don't care either

22:59:26 [sandro]

sandro: do we push on OWL about subtype of string? -- no one cares.

23:00:28 [sandro]

DaveReynolds: owl:real only makes sense when the value spaces for numerics overlap. So it makes no sense for us.

23:01:00 [sandro]

jos: owl:real would still be a way to test if it's a numeric.

23:01:19 [sandro]

DaveReynolds: I wouldn't object to owl:real, but it seems unnecessary.

23:02:00 [sandro]

jos: no pred:isNumeric

23:02:07 [sandro]

DaveReynolds: that's a problem.

23:02:23 [sandro]

jos: So let's use isLiteralOfType(...., owl:real)

23:03:52 [sandro]

sandro: so owl:real is just a union type of all the numeric xsd types.

23:03:57 [DaveReynolds]

+q

23:04:40 [DaveReynolds]

q-

23:05:35 [sandro]

DaveReynolds: I agree with Jos, except we should use owl:realPlus. Also NaN, -0, +inf, -inf. Since those are part of the double valuespace.

23:06:11 [josb]

I agree w. Dave, since we indeed have double

23:06:23 [sandro]

DaveReynolds: but OWL RL has owl:Real to avoid reasoning-by-cases.

23:07:33 [sandro]

sandro: rofl that NaN will pass the "numeric" test we're talking about.

23:07:48 [josb]

would could take both owl:real and owl:realPlus

23:08:37 [sandro]

+1 to both.

23:09:04 [josb]

dave, is owl:datetime a subset of xsd:dateTime?

23:09:19 [DaveReynolds]

can't remember, just trying to find def

23:11:13 [DaveReynolds]

They actually call it xsd:dateTimeStamp

23:11:50 [DaveReynolds]

"Feature At Risk #3: owl:dateTime name

23:11:52 [DaveReynolds]

The name datatype owl:dateTime was previously used as a placeholder. XML Schema 1.1 Working Group has introduced a datatype for date-time with required timezone. The datatype owl:dateTime was thus changed to the new datatype, xsd:dateTimeStamp. which is described here in a way compatible with its expected definition in XML Schema. If the XML Schema WG proceeds as expected, this section may...

23:11:53 [DaveReynolds]

...be removed in favour of a pointer to the XML Schema documents."

23:12:38 [sandro]

PROPOSED: Add owl:dateTime (with the same AT RISK caveats as in the current OWL drafts, ie xsd:dateTimeStamp), owl:real, owl:realPlus to Core, PRD, BLD. Not owl:rational. This will replace xs:dateTime (currently in DTB).

23:18:11 [sandro]

PROPOSED: Add owl:dateTime (with the same AT RISK caveats as in the current OWL drafts, ie xsd:dateTimeStamp), owl:real, owl:realPlus to Core, PRD, BLD. Not owl:rational. This will replace NOT xs:dateTime which has no real time semantics but is still present in real data, so implementations should make their best guess.

23:18:24 [DaveReynolds]

-1 is SHOULD replace xs:dateTime

23:18:32 [DaveReynolds]

s/is/it/

23:19:24 [sandro]

DaveReynolds: Any processor getting xs:dateTime data can map it to xs:dateTimeStamp.

23:20:07 [sandro]

csma:what about existing schemas using xs:dataTime?

23:21:29 [sandro]

DaveReynolds: as part of the mapping for XML data to RIF, you do the conversion from xs:dateTime to xs:dateTimeStamp.

23:22:00 [sandro]

csma: does this change the semantics of the rule?

23:22:14 [sandro]

DaveReynolds: No more than the error already there in the missing timezone.

23:22:50 [sandro]

DaveReynolds: Danger is you don't round trip. The data would go back out as xs:dateTimeStamp.

23:23:17 [sandro]

GaryHallmark: I can imagine rules that rely on local time zone.

23:23:58 [sandro]

DaveReynolds: in the XML schema mapping, we COULD say, the default assumption SHOULD BE local timezone.

23:24:31 [josb]

PS I just realized that in this case, our equality (which is identity) is different from dateTime-equal

23:25:22 [josb]

actually it is not

23:26:03 [josb]

in XSD, equality between non-timezoned datetimes can be determined

23:26:28 [josb]

http://www.w3.org/TR/xmlschema-2/#dateTime-order

23:29:18 [sandro]

PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they SHOULD use the local timezone and SHOULD give a warning in doing so.

23:29:40 [josb]

if both datetimes either do or do not have a timezone, comparison works as you expect

23:30:05 [josb]

if one does and one does not have a timezone, it becomes tricky

23:30:49 [DaveReynolds]

Suggest replacing first SHOULD with MAY

23:30:52 [sandro]

PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they SHOULD use the local timezone and SHOULD give a warning in doing so.

23:31:03 [sandro]

PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime, but require systems to accept it, and when getting dateTimes without a timezone, they MAY use the local timezone and SHOULD give a warning in doing so.

23:32:58 [DaveReynolds]

PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). We'll remove support for xs:dateTime. We anticipate that our XML Schema to RIF mapping will specify mapping xs:dateTimes to xs:dateTimeStamp, such a mapping MAY use the local timezone but SHOULD give a warning in doing so.

23:33:16 [josb]

+1

23:33:24 [sandro]

PROPOSED: We'll add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). xs:dateTime will no longer be supported by RIF. On receipt of xs:dateTime data without a timeZone (ie not an xs:dateTimeStamp), systems MAY use the local timezone and SHOULD give a warning in doing so.

23:33:27 [AdrianP]

DateTime is well known in many programming languages

23:33:40 [AdrianP]

it can be transformed into the Epoch value

23:33:50 [sandro]

sorry -- Dave, is mine the same?

23:35:05 [sandro]

Proposed: Add xs:dateTimeStamp (assuming it matures to replace owl:dateTime). Keep xs:dateTime as at Risk.

23:35:50 [sandro]

csma: I expect implementors of RIF to handle them both, by mapping them both to stuff in their local system.

23:36:09 [josb]

why have both?

23:36:24 [sandro]

DaveReynolds: We'll have BOTH in DTB, with BOTH having comparion operators, and comparisons between the two?

23:37:59 [josb]

I will object to having both

23:37:59 [sandro]

jos: it's horrible.

23:38:10 [DaveReynolds]

Succinctly put :-)

23:39:03 [sandro]

csma: seems like we have to table this issue

23:39:17 [sandro]

gary: yeah, it's broken -- I just don't know how much we depend on the way it's broken.

23:42:05 [sandro]

sandro: (with jos) the bad situation is that you cannot compare two times when one has a time zone and one doesn't, and they're within 14 hours of each other. the comparison is not defined.

23:43:11 [AdrianP]

the timezone is simply an extra agrument in adition to the DateTime value

23:43:53 [sandro]

gary: might get timezone added by the translator, instead of the system doing the rule execution.

23:44:10 [DaveReynolds]

q+

23:44:19 [sandro]

ack DaveReynolds

23:44:22 [csma]

ack dave

23:45:24 [sandro]

DaveReynolds: if you want local time zone semantics, then let's have a built-in "compare in local time zone".

23:46:35 [sandro]

Sandro: If Gary is relying on local-time-zone semantics, then yes, he should xlate his rules to use that built-in.

23:47:25 [sandro]

action: Gary to investigate what sort of local time zone semantics (ie java.Calendar semantics) his rulesets need.

23:47:25 [trackbot]

Created ACTION-694 - Investigate what sort of local time zone semantics (ie java.Calendar semantics) his rulesets need. [on Gary Hallmark - due 2009-01-22].

23:48:41 [sandro]

csma: It seems very risky to fix this bug, because people are relying on this broken behavior

23:49:07 [sandro]

csma: or people MIGHT be relying on it

23:49:41 [sandro]

DaveReynolds: But that behavior, being undefined, is not interoperable.

23:53:23 [josb]

equality is not a problem

23:54:33 [sandro]

sandro: this will manifest on date-less-then being undefined sometimes (when one tz is missing)

23:55:18 [sandro]

sandro: I strongly expect most rule engines do not do this kind of datetime comparison.

23:57:22 [DaveReynolds]

+q

23:58:08 [csma]

ack dave

23:58:13 [sandro]

we have three options: (1) xs:dateTime, (2) xs:dateTimeStamp, (3) try to document java semantics.

23:59:50 [sandro]

DaveReynolds: Gary's customers are probably assuming the dt semantics Gary has implemented. So when Gary translates to/from RIF, he needs to map to/from those semantics.