RE: Tracking Core Component use

["Welsh, David" <David.Welsh@nordstrom.com>]

Although it sounds like a 'neat' technical mechanism and you may think it doesn't apply, I can imagine the subject of "the Registry can tell us which core components and varients are most often used" might be risking some privacy scrutiny; being a public standard on the public Internet ?!! 
As opposed to early days of B2C when there wasn't a lot of focus, Internet privacy today is a very very serious business issue. Does that apply for B2B, .. I'm not sure but as a business end user I know of many instances when company's don't want others to see what data and trading relationships are
being thought of and conducted. 
I can also imagine there's a few interesting legal questions that might be asked about what laws/rules govern RegRep ops.

You asked for some "thoughts here".
-Dave


> -----Original Message-----
> From: David RR Webber - XMLGlobal [mailto:Gnosis_@compuserve.com]
> Sent: Thursday, September 27, 2001 6:32 AM
> Cc: 'regrep@lists.oasis-open.org'
> Subject: Tracking Core Component use
> 
> 
> Team,
> 
> I'd like some help and thoughts here.
> 
> In the course of the core component work I'm doing 
> someone said 'of course the Registry can tell us which
> core components and varients are most often used,
> and that will help people choose the right ones when
> starting something new'.
> 
> This is an intriguing idea.  Sorta like those download
> counts from shareware.com - but in our case it 
> needs to be probably when a machine API requests
> the definition of a core component, and then given
> the vaguaries of the internet - coupled to something
> like the capabilities of a tool like Webalizer to show
> some demographics.  Otherwise Ford accessing
> just one core component a million times could 
> distort the numbers.
> 
> I'm not sure we have anything in the current design 
> of Registry that would allow us to support this 
> 'most popular core components' need?
> 
> Could we hook some of the existing pieces - like
> audit trail, and the API, and a Webalizer tracking 
> thru the webserver - together to deliver here?  Also - we
> need to drilldown into the goals and requirement 
> a bit more.  So long as we can offer up a selection 
> of statistical data points - we can allow solution 
> providers to tee these up to answer questions 
> as needed.   That saves us having to get into 
> the reporting side of this - we can leave that
> open-ended.
> 
> Thanks, DW.
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>