[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep-cc-review] Kickoff!
Joe, See my inserts below <dw/>. Thanks, DW. Message text written by "Chiusano Joseph" > and what if there is NO available XML format?!? >> There will be - that's what we are creating. <dw> ??? Now I'm confused - we're creating XML for UML models? </dw> why would we want to store the other binary goup - since we can't do anything with that meaningful!!! >> An ebXML registry can store this as an Extrinsic object. <dw>Exactly what I said - so we do not need XML formats for these</dw> If the CCTS folks already think they have that "available XML format", >> They don't - that's our job <dw>But what are the requirements here? </dw> then we need to realize that any non-XML gets either stored as a binary - or a pointer to its extrinsic instance. >> Yes - how is this different than our current registry architecture? <dw>It's not - I was merely stating the obvious</dw> And we need an XML serialization system to actually manage the semantics. >> Yes - and again, that is our mission. <dw>And to get the requirements for that serialization</dw> But we critically need to understand what those semantics are >> Please give concrete examples of what the CCTS does not provide that you think it should. <dw> There's a long list. The original CEFACT CRI document we donated across - gives extensive details. CCTS is devoid of rendering or ebusiness logical semantics mechanisms. They also have no notion of relating sets of vocabularies together - (we might just need that for a federated registry system) - and being able to cross-walk. There's also little support for what the OASIS CIQ folks are doing with Address, and being able to link 207 countries postal definitions worldwide together around the single semantic core, and then have that re-usable as XML that can be assembled as needed. And then there is support for automated language usage - particularly in rendering. And then there is codelists. Turns out UBL is working on codelists in XML. So is UN/eDocs, so is ATG. Since codelists are a critical core component type - we need a clear way of not just representing them - but managing them. Including subsetting and versioning. The CCTS document is quiet on this subject. The Registry obviously has the tools to support this - but we are the last people think of - when they go engineering. Since codelists are part of CCTS - we come back to my original assertion earlier - that we need a mechanism that is broadly focused - not just CCTS - since we know in the case of codelists in particular lots of folks have lots of these. Also notice we have performance considerations for codelists. There are ways we can engineer these using existing registry constructs - but we may find this would be clumsy for extensive machine requests - where the overhead of traversing nodes as opposed to be able to retrieve a single chunk of XML becomes very important. OK enough already! </dw>