[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Tracking Core Component use
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC