[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: followup: RE: PRAGMATISM: A few of my own : RE: Problems with Classificatio ns
Also, my curiousity in topicmaps is not to propose an ebXML endorsement...but to allow the support of anything. Scott -----Original Message----- From: Nieman, Scott To: 'David RR Webber ' Cc: 'firstname.lastname@example.org '; ''Sam Hunting' ' Sent: 9/30/00 8:22 AM Subject: RE: PRAGMATISM: A few of my own : RE: Problems with Classificatio ns David, I think we are agreeing. I am presenting the idea that we leave OUT of the model the detail of how a scheme is composed (i.e., Nodes, Items, Levels), because it is a debatable item, and will be for months. Let the DOM manage it; if its XML, we can figure it out and simply manage associations. I don't care if the scheme is XMI (in UML.DTD or MOF.DTD format) or a Topicmap or David's home brew. To me leaving it out is KISS. Regards, Scott -----Original Message----- From: David RR Webber To: Nieman, Scott Cc: email@example.com; 'Sam Hunting' Sent: 9/29/00 11:21 PM Subject: PRAGMATISM: A few of my own : RE: Problems with Classifications Message text written by "Nieman, Scott" > I also believe that multiple classification schemes can be assigned to the same object which Topics seems to suppport. I believe that schemes can be interrelated, which addresses a real life scenario of incorporating a common business object into UML class diagram and tracking which models use that CBO. Soooo...having said that...do we absolutely need to specify and persist a scheme's composition or do we just discover the composition of a scheme at runtime via the DOM? Perhaps we treat composition as arbitrary and move on... thoughts?? flame?? Scott <<<<<<<<<<<<<<<<<<<<<< Scott, While this is all good and fine - I believe at some point we have to go with pragmatism over theory. As Rik Drummonds mantra says - KISS. To be more precise we have to hit the 80:20 rule here of business functional need. It is true that we COULD do all kinds of wonderful things with a Reg/Rep model - some of this however we need to sensibly decide to leave to vendors like Oracle and RedBrick to do with multi-million dollar budgets. If we stick to our core need to enable interoperable simple global electronic markets - then we come up with a V1.0, that enables retrieval and interfacing at a basic level - and we want that to be obvious and therefore totally consistent across registry implementations. Now - being a good engineer - I do want to leave stay holes, clamp points and hinges that can be used in Phase 2.xx to build upon the base level implementation. I believe we are more than doing that already - and at some point we need to start very clearly figuring what is going to ship in V1.0 here. Once we have a market implementation (about Q2/2001 say), and have been running it for 6 months globally - then I think we can come back and revisit on what the marketplace needs are showing for V2.0. Till then we should be VERY careful to avoid over engineering. For now people can clearly save and retrieve Topicmaps into the Registry, and they can use GUIDs to associate to whatever they like - I'd say we are pretty much done at this point, right there. Thanks, DW.
Powered by eList eXpress LLC