Re: Cool Features - Was: (Re: Examples Are Somewhat Confusing)

[Skip Montanaro <skip@xxxxxxxxxxxxxx>]

Okey dokey.  I'm feeling especially opinionated today.  (Perhaps it's lack
of sleep and too much Pepsi...)  Tim stated the issues so eloquently.  How
can I not cast a vote? :-) (Actually, I will avoid voting on item #4...)

Tim Howes writes:
   
   	1) Ordering of attributes within a body part (i.e., should we
   	   require all the CNs come together).

Are there any situations where the adjacency of two attributes would imply
something?  If so, then I believe there's an overall design problem with the
spec (the two adjacent attributes would be one logical attribute and should
be specified as such).  If not, then I favor not having any ordering
constraints on the attributes for one simple reason.  Applications that
parse these beasts should be tolerant of incorrectly ordered attribute
lists.  There will be some that don't conform to the spec, no matter how
tightly you specify it.  If parsers should be lenient, then they will have
no choice but to assume nothing about the ordering of the attributes, so why
require it?

   	2) The datatype parameter (should it exist at all, be optional
   	   or required, etc.).

If we're talking vCard-like things, I can understand where having explicit
data types is useful (WAV, vs AU sound bites, GIF vs PNG or JPEG logos,
etc).  I find it hard to imagine where the type of a vCalendar-ish sort of
attribute wouldn't be obvious from the name of the attribute itself.  I
implemented vCalendar generation in our event calendars quite easily.  There
was no wailing and gnashing of teeth.  ("Oh no! They required the GEO
attribute to use decimal numbers! Don't those bozos know degrees/minutes/
seconds is the best way to do lat/long coordinates?" :-) If you allow
multiple data types for various attributes you'll have to specify what every
possible data type is, all parsers will have to handle each and every data
type, and (in the words of a famous unnamed columnist, "I kid you not"), for
each attribute one particular data type will be adopted by almost everyone,
so you'll wind up with a bloated parser containing a bunch of dead code.

Ergo, I say decide what the "best" data type is for each attribute, go with
implicit typing and avoid all the hoo haw about optional vs required data
types altogether.

   	3) Saving space for repeated values of the same type.

Hogwash.  #3 implies #1.  I can't for the life of me understand how saving a
couple bytes for repeated attributes is going to benefit anyone.  Returning
to vCard as an example, I occasionally get email from someone who shall
remain unnamed.  His messages are always a few hundred lines long, so I
think, "Hmm, this must be pretty important.  I'd better read it."  Lo and
behold, his messages are in reality only a couple lines long, but he always
states, "Here's my vCard information in case you need to contact me."
Naturally, he's taken full advantage of the capabilities available.  There's
a corporate logo and an introductory sound bite.  His vCard is tens of
thousands of bytes long.  How is omitting an occasionally repeated attribute
going to save anything?

Now return to a hypothetical C&S example.  Your boss calls a meeting and
zips off the "invitee" list.  His C&S tool being so easy to use, and bosses
being who they are, he invites everyone under him, and the entire management
chain above him all the way to the CEO.  (Sorry about the gender reference
ladies.  I'm picturing a certain "pointy-haired" boss from the comic
strips...)  Okay, so you've got 80 gazillion people invited to the meeting.
You could avoid the repeated attribute name for the invitees, but why
bother?  Most of the invitees' names will be substantially longer than the
attribute name anyway.

So where's the savings in repeating attribute names?  What attributes
besides attendees/invitees are likely to be repeated?

Skip Montanaro     |   Musi-Cal: http://concerts.calendar.com/
skip@calendar.com  |   Conference Calendar: http://conferences.calendar.com/
(518)372-5583      |   Python: http://www.python.org/