followup: RE: PRAGMATISM: A few of my own : RE: Problems with Classificatio ns

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

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: 'ebxml-regrep@lists.ebxml.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: ebxml-regrep@lists.ebxml.org; '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.