Subject: Re: SKiCal component property extension - LANGUE

From: Pär Lannerö <[email-masked]>
Date: Thu, 01 Feb 2001 12:20:21 +0100

John Stracke wrote:
> Greg FitzPatrick wrote:
> > Property Name: LANGUE
> This sounds like a useful property to have, but the name is pretty confusing;
> it's too close to LANGUAGE.  Perhaps EVENTLANGUAGE?

Entendu :)

This is not a very important decision, but we thought it would be nice
to mix in french when doing an internationalization property.

LANGUAGE is a property parameter, while LANGUE is a property, so the
risk of confusion shouldn't be that great. Besides, mostly _machines_
will read the raw files and data streams, and if somebody attempts to
implement a calendaring app by reading sample files instead of specs. he
will probably recognize that "LANGUE:de" has something to do with
languages, and what could that be except for an indication of what
language is being used at the event? 

Pär

---

From: John Stracke <[email-masked]>
Date: Thu, 01 Feb 2001 10:51:41 -0500

> to mix in french when doing an internationalization property.

Mmm, I can understand that; but I think it's counterproductive.  First, in order
to work with this standard, you pretty much have to be able to read English, since
that's the only language the RFC is published in.  Using non-English words feels
like being inclusive, but it's really being *exclusive*, because you make it
harder on the reader; they now have to understand *more* languages.

Second, using a word that's close to another word in the same specification is
confusing to everybody, no matter what their language.  In particular, consider
the case of someone who does not natively speak any European language; it's not
necessarily going to be obvious to them that LANGUAGE and LANGUE are different
words.  (Or, contrariwise, it might not be obvious that they're *similar* words.)

> will read the raw files and data streams

If that were relevant, we'd still be using ASN.1.

We're doing a text-based protocol because text-based protocols are easier to
prototype, understand, and debug.  Those advantages are usability advantages,
advantages of human interface.  They go away if you ignore the rules of usability;
and one of the most important rules is that you must not confuse the user (in this
case, the programmer).  If two entities in the interface are different, they must
not look the same.  Context helps a bit, but it's not enough.

> he
> languages,

Provided his native language and/or his understand of English allows him to
recognize that LANGUE is related to LANGUAGE.  It seems obvious to me, but I'm
steeped in European languages.  I would have no clue how to recognize related
kanji; I don't think it's fair to expect a native speaker of an Asian language to
recognize related English and French words.

(Nobody take offense, please; I'm *not* saying I assume Asians would have
trouble--I'm sure many or most would handle it fine--I just don't think it's a
reasonable burden to impose.)

> and what could that be except for an indication of what

> language is being used at the event?

Lots.  It could be the default value of the LANGUAGE parameter.  It could be the
language in which the ORGANIZER wishes you to reply.  It could be a bit of random
cruft, inserted by a nonstandard CUA, indicating the language of the user who
composed the iCalendar.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Both candidates are better than a megalomaniac |
[email-masked]|mutant lab mouse bent on world domination...but|
|                |it's pretty close.                             |
\================================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 1 Feb 2001 17:53:17 +0100

While preparing the submission of the SKiCal PROMO property, I ran into a
little trouble and I wonder if anybody can help me out?

The idea with PROMO is that it would help to keep promotional verbosity
under control by keeping advertisements in appointed places so that clients
could decide themselves if they wanted to pull down 30 second commercial to
their PDAs and so on.

We based PROMO on ATTACH, which is basically a URI place holder. Looking
again at ATTACH it appears to me that there is no method for describing what
the attachment actually contains.  Though you can say what type of
attachment it is - you can not say "what it is about".

In the 2445 examples this is not readily apparent since the URIs exemplified
use self explanatory names like;

ATTACH:http://xyz.com/public/quarterly-report.docor

FMTTATTACHYPE=application/postscript:ftp://xyzCorp.com/pub/
      conf/bkgrnd.ps

We surely cant count on this always being the case.  In the example below
the DESCRIPTION is used to solve the problem, but that seems not to be a
good approach - certainly not in the interest of promoting machine
understanding;

DESCRIPTION:A draft agenda needs to be sent out to the attendees
       to the weekly managers meeting (MGR-LIST). Attached is a
       pointer the document template for the agenda file.
     ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen
      da.doc

It seems what is missing is the altrep mechanism, which gives both the URI
and a textual representation of what is to be found at that URI, but altrep
is not given as a value option for ATTACH.

Any comments?

btw. Erik there is a 2445 typo in that last example .. a pointer (to) the
document..

---

From: John Stracke <[email-masked]>
Date: Thu, 01 Feb 2001 12:44:37 -0500

> could decide themselves if they wanted to pull down 30 second commercial to

A feature designed to contain advertisements, which gives the user control over
whether to view the advertisement, will never be used; it's not in the
advertiser's interests.

Several of your features seem to be targeted at advertisers, but would not be
useful to them.  Case in point: the example you give in the section on SUMMARY
(section 4.8.1.12, which is contained in section 4.1).  You advocate replacing:

     SUMMARY:Macy's once a year white sale. Up to 50% off on some items.
     We are featuring Cramer & Houghton bedding, Epousant pillow covers,
     Jantzen towels.
     CATEGORY:Department Store

with:

     TITLE:Macy's once a year white sale(c)
     CATEGORY:Department Store.sale
     THINGS;ROLE=onsale:Cramer & Houghton bedding, Epousant pillow covers,
     Jantzen towels,

In the latter version, there is no free-form text, no chance for the advertiser
to be persuasive.  Sure, it's searchable, but so what? Some people will manage
to find the ad by searching for "pillow covers"; but the ad won't be persuasive
when they find it, and it certainly won't get the attention of people who
weren't already in the market.  The advertiser might benefit from being able to
do *both*--provide both the metadata and the full text--but your 4.8.1.12
recommends using SUMMARY for a very brief title, or not at all.

(This actually calls up another point: SKiCal objects may be technically
compatible with iCalendar; but, as things stand, there's a strong risk that
someone using a base iCalendar implementation won't be able to see much
information.  If SUMMARY goes away and is replaced with metadata which is
invisible to iCalendar, then my iCalendar app will show an event with no
summary, and the users will be left scratching their heads.)

Similarly, the PERSONS, THINKS, and THINGS properties may be useful as
metadata, but they're woefully inadequate for a rich description of the event.
Your "THINGS;ROLE=PRESENT:Car models of 2001" (section 3.2) is much less useful
to an advertiser than "SUMMARY:Come on down and see the new 2001 Ford Pinto!
Now with 35% fewer fatal explosions!"

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Te audire no possum. Musa sapientum fixa est in|
[email-masked]|aure.                                          |
\================================================================/

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 1 Feb 2001 22:23:26 +0100

>whether to view the advertisement, will never be used; it's not in the

I don't agree. It is in the advertiser's interest to reach the people 
which are interested in whatever things the adevertisment is about, 
and at the same time not create negative value on the trademark he 
owns.

One way of making people happy while still sending out information is 
to let the user have control over whether the information should be 
displayed or not.

>summary, and the users will be left scratching their heads.)

A specification of a schema will always be extended. See the SNMP 
specs. I presume that if someone want to create a really good 
iCalendar application, it should be able to understand the current 
RFC for iCalendar (which might be updated one day) and also the 
extensions also published as RFC's. The one day a spring cleaning is 
happening and a new version of iCalendar is published and that might 
include the properties that SKiCal have.

So, I would be a little bit less negative to new properties than what 
I feel many people (I am not pointing at you John) on the iCalendar 
list has.

Instead, see that iCalendar is a success, just because the SKiCal 
group want to use it, BUT, need some new properties because the 
iCalendar objects are no longer used to describe the same kind of 
"things" as what was (maybe) originally planned.

Yes, you should (as you do John) see if the problem which the SKiCal 
people have can be solved by existing properties, but if that is not 
possible, then "just" create new ones and extend iCalendar to be able 
to use for this new usage.

     paf -- as individual and not as area director, the call of where
            this discussion is going, and consensus, is with the wg chair

---

From: John Stracke <[email-masked]>
Date: Thu, 01 Feb 2001 17:02:02 -0500

> to let the user have control over whether the information should be

Um...I agree that this could make sense in theory; but advertisers obviously don't
believe it.  That's why there's no way to skip TV ads (it'd be trivial to include
"this is an ad" markers in the subchannel, for VCRs to spot), or to go to a Web
site and say, "don't give me ads" (*).  Advertisers pay money to get their ads to
you; they're not going to pay nearly as much if you can ignore them easily.

If you go to a company and say, "we've got this format in which you can advertise
your events; it has a feature where you can put your information out of band so
users don't have to see it", they're going to stare at you in blank
incomprehension.  Why would they go to extra effort *not* to show the user the
entire ad?

> A specification of a schema will always be extended.

Yes, but SKiCal doesn't just extend; it more or less deprecates some of the
existing properties.  A specification for "iCalendar plus new metadata" would be
good; one that says "OK, make an iCalendar, but don't bother with SUMMARY, because
it's redundant with these extensions" is not backward compatible.

(*) If someone tells me there are sites that do this, I won't dispute it; but
they're at least rare enough that I've never seen one.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"What now, Brain?" "We should flee in terror.|
[email-masked]|Yes, that would be the wisest course."       |
\==============================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 2 Feb 2001 11:10:08 +0100

John

Please refrain from jumping around all over this.

Please let us introduce one issue at a time and debate the merits of that
issue.  Pat once told me, and I value this highly, "don't submit concepts
and ideas, submit proposals formulated in the syntax of the working group."

That is what we are now trying to do, after waiting patiently in the wings
for CAP do be resolved.

We started with "LANGUE."  You made good arguments for calling it
EVENT-LANGUAGE and we agree.  But then you referenced PROMO, which we had
not yet submitted and then you cited our examples of SUMMARY, which we have
not either submitted.  And now we are about to get side tracked in
discussing the motives of advertisers.

Please let us just submit these items one at a time so that we can
concentrate on the merits and weaknesses of each per se.

Greg

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 2 Feb 2001 11:50:55 +0100

Reluctantly I take up this glove.  But I suggest that any one with a limited
time schedule for philosophizing can skip all this and concentrate on the
issues.  Our proposals for the properties cited here will be presented to
the list shortly.

John:

A feature designed to contain advertisements, which gives the user control
over
whether to view the advertisement, will never be used; it's not in the
advertiser's interests.

Greg:  And what is a banner?  What is a "for more information call xxx"?
You are really off here John.  Look at any commercial web page on the
Internet.  And do you suggest that WAP and IMODE users will have no control
what-so-ever over the size of things they download?

John:

Several of your features seem to be targeted at advertisers, but would not
be
useful to them.  Case in point: the example you give in the section on
SUMMARY
(section 4.8.1.12, which is contained in section 4.1).  You advocate
replacing:...

Greg: No, No, No, we don't advocate replacing anything!!

John:...

with:

In the latter version, there is no free-form text, no chance for the
advertiser
to be persuasive.  Sure, it's searchable, but so what? Some people will
manage
to find the ad by searching for "pillow covers"; but the ad won't be
persuasive
when they find it, and it certainly won't get the attention of people who
weren't already in the market.  The advertiser might benefit from being able
to
do *both*--provide both the metadata and the full text--but your 4.8.1.12
recommends using SUMMARY for a very brief title, or not at all.

Greg:

The issue is machine discovery and machine readability.  The authors of a
schema must think in terms of place-holders which will give machines a
reasonable chance to discover what they are looking for.  These
place-holders will sort somewhere between being universally generic and
domain specific.  These are design issues.  But the authors can not  know to
what extent machine discovery and readability will become part of our daily
transactions, so the authors offer o p t i o n s.  The authors offer
mechanisms of possibilities.  Publishers and users and the market itself
will decide to what extent these are used.

John

Greg:  Again I repeat, we don't advocate doing away with SUMMARY!!!  Please
stop inferring this.

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Feb 2001 10:00:38 -0500

> Greg: No, No, No, we don't advocate replacing anything!!

4.8.1.12:

     Due to the additional SkiCal properties such as TITLE, PERSONS,
     THINGS, THINKS, it is expected that Summary be used as a short
     abstract describing the SKiSource rather then a general placeholder
     for text values sorting naturally under the new SKiCal properties.

In other words, Summary will hold less information, because of the metadata.
Then, in your example, you don't have a Summary at all.

> Publishers and users and the market itself

OK, fine.  But your draft, as written, anticipates less free-form text.  I
would be more comfortable seeing that weakened.

I'll drop this now.
--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Beware of wizards, for you are crunchy and good|
[email-masked]|with ketchup.                                  |
\================================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 02 Feb 2001 10:05:05 -0500

Greg FitzPatrick wrote:

> issue.

I'm not sure that's a good process; it winds up being too myopic.  You're
introducing a *lot* of new properties and parameters, which work together; to
some extent, at least, they need to be considered together.  At a minimum, the
group needs a guarantee that no decisions will be made on any proposal until
we've discussed all of them, so that, if the discussion of proposal #17
uncovers a problem with proposal #3, we're not already committed to accepting
#3.

> But then you referenced PROMO, which we had
> not yet submitted

You published it as a Draft, which implies you're looking for comments.

|eCal Corp.      |Veni, Vidi, Ridi: I came, I saw, I mocked.   |
[email-masked]|                                             |

---

From: Pär Lannerö <[email-masked]>
Date: Sat, 03 Feb 2001 00:29:03 +0100

> Then, in your example, you don't have a Summary at all.

You're right, we should put a Summary in the example. We never intended
to change anything about SUMMARY. Only to add other properties. 

> I'll drop this now.

John, we (ie. the authors of the SKICal draft) are very thankful for
your efforts to read and comment on the draft. I sincerely appreciate
your contributions and I hope you will not drop this altogether!

/Pär

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 2 Feb 2001 17:47:09 +0100

No argument here.  It is just that we are trying to consider each SKiCal
item very carefully ourselves as we submit them here, in that sense we are
reviewing the draft you quote. Once this round is completed we will correct
and deplete and amend before the last call.  For example your EVENT-LANGUAGE
name change suggestion looks like it will be incorporated.

Of course the draft is published hoping for comments, but I hope it will be
easier to focus on the items in the order we introduce them.

Greg

> Please let us introduce one issue at a time and debate the merits of that

John wrote:

I'm not sure that's a good process; it winds up being too myopic.  You're
introducing a *lot* of new properties and parameters, which work together;
to
some extent, at least, they need to be considered together.  At a minimum,
the
group needs a guarantee that no decisions will be made on any proposal until
we've discussed all of them, so that, if the discussion of proposal #17
uncovers a problem with proposal #3, we're not already committed to
accepting
#3.