RIF Telecon 20 May 2008 -- 20 May 2008

<ChrisW> Dave, you ok to scribe?

Yes, once I manage to get on the call - having problems with the relay.

<sandro> I had trouble getting on, too. okay now, though.

<JeffP> (I am at IRC only)

<scribe> Scribe: Dave Reynolds

<scribe> ScribeNick: DaveReynolds

Admin

<ChrisW> http://lists.w3.org/Archives/Public/public-rif-wg/2008May/att-0119/05132008-rif-minutes.html

<ChrisW> PROPOSED: Accept May 13 telecon mins

<ChrisW> RESOLVED: Accept May 13 telecon mins

<csma> ACTION: to chris to ask mdean for the May 6 minutes [recorded in http://www.w3.org/2008/05/20-rif-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - to

<ChrisW> http://www.w3.org/2005/rules/wiki/F2F10

Draft agenda for F2F10 meeting now available

<csma> ACTION: chris to ask mdean for the May 6 minutes [recorded in http://www.w3.org/2008/05/20-rif-minutes.html#action02]

<trackbot-ng> Created ACTION-479 - Ask mdean for the May 6 minutes [on Christopher Welty - due 2008-05-27].

Chris: main objectives for F2F is to publish BLD and SWC as last Call docs
... and move the other documents to next working draft

<sandro> Chris is discussing http://www.w3.org/2005/rules/wiki/F2F10#Schedule_.26_Topics

Chris: aim to resolve decisions by am of 2nd day all for SWC and by end of second day for BLD
... may finish a little early on day 3 apart from editors

Sandro: there has to be an official end time

Chris: make 3pm official end time of day 3?
... [after discussion] OK, so leave it as 5pm.
... the topics have been up for a while but please review

Igor: why isn't FLD going to Last Call?

<Harold> Igor, Michael and I were also quite surprise about FLD no longer being a on rec track.

Sandro: FLD is a little more open since no one will implement it directly and Last Call should focus on implementations

Chris: FLD hasn't had enough review and feedback yet

<Harold> Soon we will need FLD for PRD.

<Harold> (2nd instantiation)

<Hassan> hak -> harold : good luck ! ;-)

Igor: move UCR earlier in the agenda?

<Harold> hak, at least what we need for CORE.

<Hassan> hak -> harold : yeah - even JUST that ... good luck ! ;-)

<Harold> (a common core of FLD)

Action Review

Action-452 is completed (will discuss at F2F)

<AdrianP> yes, Igor sent a review for UCR

Action-434 closed

Action-470 closed - review scheduled on F2F

<AdrianP> yes

Liason

<csma> action-470 closed

<AdrianP> nothing

UCR

Adrian: currently each use case describes scenario, motivation, requirements
... added concrete examples now that BLD syntax more stable
... reviewers felt requirements and motivations are not so important and should be removed
... second question is whether to tailor the use cases to BLD, whereas currently they are more general - e.g. events

csma: so would just keep the use cases in the document?

Adrian: compromise from Gary would be to compact the requirements into a smaller section separated from the use cases

<AdrianP> http://lists.w3.org/Archives/Public/public-rif-wg/2008May/0135.html

<Harold> Compactifying the reqs is a good way to to go at this point.

Gary: just summarize them, get rid of the pictures and the two levels of goals/csf
... drop "critical success factors" and drop the cross-links between the use cases and requirements (because they are uneven)
... some of the links are a stretch and some are missing, just remove them

Chris: it is common to have such links, maybe they need to be more complete?

csma: remove one direction? Leave the motivated-by list but drop the forward links from the use cases?

Chris: up to Adrian but if have the links one way it seems trivial to have them both ways

csma: the explanations are the problem - they are too uneven - drop the motivation explanation?
... in principle the motivation sections are a good thing but the current ones sometimes don't make sense

Adrian: the original idea of the motivations was to motivate different dialects but currently not clear

<AdrianP> there is a terrible echo

Gary: the current very fine grained linkage is too much, would be happy to just have coarse grained link in the requirements section rather than point by point justification

Chris: loath to loose work we've already done, the current structure was a result of previous reviews

<Hassan> I agree with Chris

<AdrianP> we don't loose the requirements if we only delete the motivates section

Igor: agrees that the motivates sections and links got in the way.
... would also drop the critical success factors
... the requirements are self-evident and don't need individual use case links
... would drop both the motivates section on each UC and the whole requirements section so UCR -> UC

<Harold> I agree with Gary's 'summary-reqs' proposal.

Gary: abbreviate the requirements section but leave it in would be OK, just drop the links and separate motivates sections, summary where we are on requirements and which have been met or not

Chris: as a process matter it may be pretty difficult to completely get rid of the requirements section

<AdrianP> +1 with Garry

<AdrianP> Use Case and Requirements somehow belong together

Sandro: could put the deleted bits (motivates text, critical success factors) into some design analysis document?
... the last published version of UCR didn't have the motivates sections, though did have the critical success factors

<LeoraMorgenstern> It would be good if it were well done.

<LeoraMorgenstern> The problem is that it is uneven.

csma: need to keep the specific requirements, e.g. the implement-by-translators

Chris: but could take some of the goals section and summarize as an intro paragraph to the requirements section
... so actions are remove motivates section from use cases, remove goals section and try to summarize as an intro to the requirements section

<Harold> Process-wise, can we point out into W3C wiki pages from W3C publications?

Chris: what about RIFRAF?

Gary: reads like an outline of some future document, not clear enough as it stands

Igor: RIFRAF should go out, didn't find it relevant

Chris: several of the requirements use the word "cover" which was hard to pin down. If take out coverage section maybe reword those requirements, use some more informal word like "supports"?

Sandro: not a change to make lightly

Adrian: should have it before the F2F

Sandro: misusing the presentation syntax, <> around curis, just get rid of the <>

Adrian: have to update the examples with latest change, also to have more frame logic examples

XML Style

<Zakim> sandro, you wanted to say curie syntax seems wrong (uses "< ...>" which it should not)

<sandro> STRAWPOLL: The XML syntax for BLD should avoid abbreviations, using eg Variable instead of Var

<JeffP> (Sandro, I am on IRC)

<AlexKozlenkov> (Sandro, I am on IRC)

<sandro> Harold: we talked about Const vs Constant, at great length. We can't just say "Constant" for the mathematical set.

<sandro> csma: the terms "Var" and "Const" are VERY WIDELY used. But "Pred" vs "Predicate" is a better example.

csma: Const and Var are sufficiently common that they are not good examples, Pred etc are less common

<AdrianP> +1 with csam

<JeffP> +1 with csma

Hassan: doesn't follow the argument for e.g. Const v. Constant, why not call it by it's full name?

<csma> +1 with calling Const 'foobar' instead

Harold: but even for Hassan "op" was OK because it is so common, similarly "Const" is similarly a kind of symbol but if you spell it out as "Constant" it can't be used in a math text

csma: if we agree some can be abbreviated because those abbreviations are so common we then have a problem that we have to decide case by case which ones to use - it would be easier to just do one or other everywhere

<AlexKozlenkov> "Constant" sounds like it almost comes from physics

<ChrisW> 1: Use abbreviations everywhere

<ChrisW> 2: Use full names everywhere (no abbrevs)

<ChrisW> 3: Use abbrevs when common/familiar

<ChrisW> 4: Decide on a case by case by basis

<GaryHallmark> sure, WTF...

<csma> wrt 3: who decides what is common or familiar?

<AlexKozlenkov> op. 3 creates process issues

<GaryHallmark> I'll ask my kids what the cool new text abbrevs are, lol

Harold: can't vote for 1, because e.g. that would mean using "declare" instead of "dec"

csma: case 1 is "allow" rather than force abbreviations everywhere [scribe couldn't follow the point]

Sandro: why can't we use the world "Constant" in the mathematical English?

<AlexKozlenkov> "Constant" as in fine-structure constant, sorry, difficult to accept

Harold: because want to be able to write the maths without font switches so the words have to separable form the rest of the text

<AdrianP> there is a distiction between definabel and computable constants

<sandro> Harold: the term "Constant" when it occurs in the text doesn't stand out as a symbol.

<Hassan> ???

Harold: better to use a new word for the name of a set to make the semantics text clearer

<csma> The point was just that allowing abbrev did not mean allowing aliases: if we abbreviate "declare" as <dec>, the tag <declare> does not exist (as Harold seemed to suggest)

<sandro> Chris: paraphrasing Harold: It's better to use a new made-up word, instead of re-use an existing word, for sets in the semantics.

<Zakim> sandro, you wanted to ask Harold why we can't use "Constant"

<Hassan> ++++1 with Dave

<csma> +1 with Dave

<sandro> DaveReynolds: but isn't this question about the XML? I don't need the mathematical english to use the same word as the XML syntax tag.

Harold: to simplify the mapping of the semantics to the syntax, using the same word is simpler

<AdrianP> there are also other arguements for abbreviations

<Zakim> sandro, you wanted to suggest rif:Constant

Sandro: one trick is to put a prefix in the mathematical english, e.g. rif:Constant

Harold: Michael probably wouldn't like namespaces in the maths

Hassan: worry about making the XML tags depend on the symbols in the grammar, grammars are not unique
... Harold wants a direct map from BNF the XML tags, but then the XML depends on the BNF grammar - the grammar is not canonical, it is the language which is canonical

<AdrianP> abbreviated XML tags are more compact -> e.g. creates less traffic on the wire if RIF rule sets are interchanged

<AdrianP> that can be critical for practical scalable applications

Hassan: which is why annotations are commonly used

Harold: XML grammars have sort of visible non-terminals, some of our non-terminals don't appear (TERM) and some (Const) appear, classical tools don't make that distinction

<sandro> [let's wrap this up with a quick strawpoll. I think we've gotten a better sense of the issue.]

<sandro> STRAWPOLL: The XML for BLD should be changed to avoid abbreviations, using eg Variable instead of Var

Hassan: the grammar might evolve in ways which don't preserve the conventions, by separating the grammar and the XML we allow more flexibility

<sandro> STRAWPOLL: The XML for BLD should be changed to avoid abbreviations, using eg Variable instead of Var

<sandro> 0

<csma> 0

<AdrianP> -1

<Harold> -1

<LeoraMorgenstern> -1 (I like option 3)

<AlexKozlenkov> -1

<JeffP> -1

<ChrisW> 0^100^100

<IgorMozetic> 0

<GaryHallmark> 0 i guess - I'd like to use more English words in PS and XML

<GaryHallmark> I think it would be silly to diverge XML and PS

<AdrianP> abbreviations should be of course meaningful

<ChrisW> Rigid RDF [13] VS concise XML [14] (and all in between)

<csma> I care about RIF XML being Rigid RDF

<csma> +1 to Gary

<sandro> STRAWPOLL: Who is interested in using rigid RDF for the BLD serialization format?

<AdrianP> What is that - rigid RDF?

Gary: seems like we are nearly there anyway, if it is a minor change, it would at least give us a justification to point to

<Harold> ...disadvantages:

<Harold> * it makes the XML syntax even more verbose

<Harold> * the elements from the RDF namespace can be confusing, even

<Harold> off-putting (especially to people who are allergic to RDF)

<Harold> * it prevents us from making arbitrary (non-striped) XML constructs

<Harold> that might be useful and elegant.

<Harold> * it's a course change, late in the day

Sandro: [describes Rigid RDF as expressed in the email thread]

<sandro> Harold: Some people don't want the little bits of the rdf namespace.

<AlexKozlenkov> @Gary, I do not understand that "justfication" point. Any _syntactic_ mention of RDF makes RIF dependent on RDF

<sandro> Chris: Who? Where? Are they on the WG?

<Harold> The Web Services community (all in XML) doesn't want dependency on rdf name space.

Harold: some production rule folks don't even want namespace dependencies like having rdf:

<Hassan> We are using RDF in JRules

csma: doesn't mind about that, rigid RDF does not require knowledge of RDF

Gary: agreed namespaces have been in XML tools for ages, that's simply not an issue

Chris: this is XML not RDF

Harold: thought the current XML, since it is fully striped, is all we need

Sandro: not quite, e.g. handling of datatypes in consts

<sandro> STRAWPOLL: Who is interested in using rigid RDF for the BLD serialization format?

Harold: OWL2 uses XML and then has mapping to RDF, propose doing same for RIF

<LeoraMorgenstern> Could someone summarize the downsides of using rigid RDF?

<ChrisW> they were put into the irc above by Harold

Sandro: that is proposed but not agreed, the normative piece is the functional syntax

<AlexKozlenkov> I do not want even to face my managers if I even mention RDF

<AlexKozlenkov> ...in any shape or form

<GaryHallmark> +1 for rigid rdf (I have nothing really for or against RDF. If our customers want it, we'll be happy to sell them some)

Sandro: pretty neutral, but one additional argument - fallback processing seems easier to write in RIF than XSLT and then in turn is easier in the Rigid RDF

<LeoraMorgenstern> Thanks, Chris.

<csma> Alex, you will not have to mention RDF. Somewhere deep inside a RIF document, sometimes, there might be a reference to the RDF namespace...

<sandro> STRAWPOLL: Who is interested in using rigid RDF for the BLD serialization format?

<sandro> +0.5

+0.5

<Harold> -1

<AlexKozlenkov> -1

<IgorMozetic> 0

<AdrianP> -1

<Hassan> All these problems again are caused by dependence on the grammar ....

<JeffP> 0

<csma> +1

<AlexKozlenkov> I'm going to lose all support here even of RDF is mentioned

<csma> I just got cut off by Zakim...

<AlexKozlenkov> *if

<AdrianP> and we should not map to rdf datatypes

<csma> Alex, RDF will NOT be mentionned

<sandro> AlexKozlenkov, it's very frustrating that you're on IRC but NOT the call.....

<AdrianP> I also was thrown out

<sandro> calling back AdrianP

<Harold> -1 (from Michael)

<GaryHallmark> +1

<GaryHallmark> Alex, mere use of the rdf namespace does not commit you to rdf any more than having an rdf mapping to frames commits you to rdf

<csma> I understand that the cost is near zero, and I heard people saying they found it useful

<csma> PR people, btw...

<ChrisW> testing

<AdrianP> XML Schema Part 2: Datatypes are very well known in many communities but I don't think that people want to read about RDF datatypes if they don't care about RDF

<AlexKozlenkov> it seems like an entirely unnecessary sneaking of RDF via back door

<csma> We already have RDF datatypes, btw...

<csma> Harold, you have already the RDF namespace in BLD

<sandro> Sandro: Harold -- are there any technical reasons? Or is this solely marketing reasons?

<csma> # rdf:XMLLiteral

<csma> # rif:text

<AlexKozlenkov> For me, web services is key, I cannot see RDF making it there--at all

<GaryHallmark> harold, there is nothing really to "buy into"

[Not as scribe] - Alex the proposal is not RDF but XML, there is zero impact on web services

<GaryHallmark> all web services use namespaces

<sandro> AlexKozlenkov, just because of Bad Blood? Or is there some technical reason?

csma: already have rdf namespace in RIF at least for some literals

<AlexKozlenkov> and any rdf namespace is not the one I would like to see there

Harold: the current syntax is better and took a lot of work to get here. And can use stripe skipping on it.

Chris: so can't you stripe skip the Rigid RDF syntax?

<sandro> FWIW, as I replied to Gary -- I don't *think* you can stripe skip & be extensible.

<AlexKozlenkov> Guys, it is about extending the reach of the standard, the smaller the dependencies, the better

<AlexKozlenkov> It is Occam's razor again

Harold: can stripe skip the current syntax with one XSLT rule and get to the prior nice syntax

<csma> alex, Rigid RDF means zero dependency

<sandro> Ah -- oh, maybe this kind of skipping single-property slots.... maybe.

[Not as scribe] As a reviewer I did NOT say the proposed XML syntax was "very good"

<Hassan> +1 with Sandro!!!

Sandro: the problem with an argument based on stripe skipping is that stripe skipping harms extensibility and metadata everywhere

<AlexKozlenkov> OK< so why are you calling it Rigid "RDF"?

<AdrianP> bye

<csma> because it makes the XML parsable by an RDF parser.

<JeffP> bye

<sandro> ROFL, AlexKozlenkov. I'll try to think of a better name!

<csma> Pars-able. Does not mean you have to do it

<csma> but people who want to do it, can

<csma> So, it extends the reach

- DRAFT -

RIF Telecon 20 May 2008

20 May 2008

Attendees

Contents

Admin

Action Review

Liason

UCR

XML Style

Summary of Action Items

Scribe.perl diagnostic output