OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[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


Message text written by "Nieman, Scott"
>
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.

<<<<<<<<<<<<<<<

Scott,

Ok -good - agreed. 

Topicmaps are definately of use somewhere - I've been tracking 
them for a while - probably in workflow and business process, and
also in defining characteristics of elements - but not something we
directly need to support 'out of the box' with V1.0.

The Node, item, levels stuff - I think the basics via linked lists and
GUID's is ok - since GUID support is a primitive - and what I think Len
is proposing (always a caveat there!) looks ok - hierarchical tree
structuring stuff we are doing already - but beyond that - I agree -
let someone use the XML itself to store more sophisticated
relations - thats what W3C schema is all about.

If you can query that using our basic access methods - cool - thats
a bonus behaviour and side effect - but maintaining and managing 
all this is out of scope for now.

Thanks, DW.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC