Subject: Removing Duplicated Info

From: George Babics <[email-masked]>
Date: Fri, 25 Oct 2002 15:26:59 -0400

Sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1, 8.1, and 8.2
contain summary defintions of properties, parameters,
and value types that are formally defined elsewhere.
Should we remove these summary defintions?

   We are simply duplicating information and we invite
unecessary work in ensuring that the definitions are
in sync. By removing them we will also make the draft
a few pages shorter.

George

---

From: Doug Royer <[email-masked]>
Date: Fri, 25 Oct 2002 13:55:13 -0600

> Should we remove these summary defintions?

They were added because many of the new terms were used
before defined, making reading difficult.

-
Doug Royer                       Work: (208)612-INET
[email-masked]                   Fax:  (866)594-8574
http://INET-Consulting.com       Cell: (208)520-4044
http://Royer.com/People/Doug

---

From: George Babics <[email-masked]>
Date: Fri, 25 Oct 2002 17:03:55 -0400

Doug Royer wrote:
>> contain summary definitions of properties, parameters,
>> Should we remove these summary definitions?
> 
> 

   We can always put the formal definitions first and remove
the duplicate information.

George

---

From: Doug Royer <[email-masked]>
Date: Fri, 25 Oct 2002 15:47:24 -0600

> the duplicate information.

The problem is that it is a circular usage. If we only use
them if they use terms that have already been defined, then
the order of the sections in CAP appear to be random.

---

From: George Babics <[email-masked]>
Date: Mon, 28 Oct 2002 12:49:25 -0500

> the order of the sections in CAP appear to be random.

   We can always put the all formal definitions in the first
sections and remove sections 2.1, 2.1.1, 2.1.2, 2.1.3, 3.3.1.
Thus section 2 will be new value types, section 3 will be
components, etc.  We will shorten CAP and remove duplicated
information.

   The definitions in sections 8.1, and 8.2 appear after
the formal definitions. We should remove them. The only
information we need to keep is whether the properties
are read only.

George

---

From: Doug Royer <[email-masked]>
Date: Mon, 28 Oct 2002 11:22:00 -0700

> components, etc.  We will shorten CAP and remove duplicated

How about we work on that in -10 - what I hope is the final rev?

For now we can agree to remove any duplicate information
when possible. However the circular usage problem still will exist.
I think we are going to need a summary of new objects so
that a new reader will not go 'what is that?' when reading
one of the formal definitions when it uses an object
that has not yet been described.

> information we need to keep is whether the properties

8.1 and 8.2 are the formal definitions for VAGANDA
and VCALSTORE.

Are you looking at -09-b-2 ?

And I am editing -b-3, it has the sections for components, properties,
and parameters separated - once I understood your email. And I am now
adding the error messages and cross referencing with 244[567].

It looks as if we are close, as a HUGE percentage of the messages
being sent are typo's, formatting, and not technical problems.

-- 
-

---

From: George Babics <[email-masked]>
Date: Mon, 28 Oct 2002 15:01:42 -0500

> How about we work on that in -10 - what I hope is the final rev?

   That is fine.

> 8.1 and 8.2 are the formal definitions for VAGANDA

   However, they also contain definitions of the
properties that they can contain. The properties
are formally defined earlier.

---

From: [email-masked]
Date: Tue, 29 Oct 2002 11:33:40 -0500

> >> Should we remove these summary definitions?
[Snip]
> the duplicate information.

I grok both sides of the discussion here but Im curious to know why we 
have a 'summary' section and then intervening sections and then formal 
definitions towards the end.  Why isnt the draft structured so that its a 
bit more like 2445?  In that I mean that we first defined our data types 
and then our properties and then we defined the usage/combination of them. 
 We didnt give a summary of them, the model of how to use the summarized 
stuff and then fhe formal definition of the new stuff.  It does seem a bit 
backwards from an organizational POV...

Reorganizing like 2445 would make reading the draft a bit easier and it 
would remove the need to have Section 2.1x marked as 'summary' and then 
more info later on in Sections 6.x, 7.x and 8.x...

For the next big rev I think Georges suggestion of 6.x, 7.x and 8.x being 
relabeled as 6.1, 6.2 and 6.2 since they are all additions to iCalendar 
and logically belong in the same section.  But Im not suggesting we do it 
for Atlanta.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...