Subject: [DMM] Fwd: Re: Editorial revisions to FPC draft

From: Charlie Perkins <[email-masked]>
Date: Thu, 16 Nov 2017 16:42:16 -0800

Hello folks,

Here are some comments that I had sent to the co-authors.  It was 
suggested that these discussions should really be carried out in a 
larger context.  Any comments will be appreciated.  I am in the process 
of receiving the editorial pen for the document and part of my purpose 
will be to reformulate some of the definitions.

Regards,
Charlie P.

-------- Forwarded Message --------
Subject: 	Re: Editorial revisions to FPC draft
Date: 	Tue, 14 Nov 2017 17:03:47 -0800
From: 	Charlie Perkins <[email-masked]>
To: 	Marco Liebsch <[email-masked]>, Satoru Matsushima 
<[email-masked]>, Sri Gundavelli (sgundave) 
<[email-masked]>, Moses, Danny <[email-masked]>, Bertz, Lyle 
T [CTO] <[email-masked]>

Hello again folks,

Regarding some of the definitions...

I'd like to suggest the following:

- "xxxx-ID" should be *defined* to be an identifier.  Not a reference.

- "xxxx-Reference" should be *defined* to be a reference.  I understand
a reference to mean a way of locating an instance.  An identifier could
be a reference, if the identifier is also an index into an array of
instances, or a key into a database (or a pointer in C  [just kidding...]).

- for the purposes of this draft, we could restrict "name" to mean a
string of ASCII characters associated to an identifier. Not associated
to a reference.  If the string IS the identifier, then I am not sure if
the identifier has to have a "name" attribute.

- this, unfortunately, conflicts with the use of the word "namespace",
which undoubtedly does NOT mean a space of strings of ASCII characters.
Maybe "namespace" should be renamed to be "id-space".

As a bit of background for these remarks, I would like to suggest that
the document is quite abstract, by intention and design.  And I think
that is quite appropriate.  But, abstraction has its costs.  For one
thing, the abstract concepts have to be defined *extremely carefully*.
Otherwise the abstraction is more difficult to grasp.  Another cost is
that the abstraction has to be well motivated.  This can be done by
offering many examples. Or, you might say, many opportunities to connect
the dots between the stratosphere and what's visible on the ground.

...

Regards,
Charlie P.
...