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


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

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

Subject: Re: [regrep-cc-review] Kickoff!


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

>> 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

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
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
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
to retrieve a single chunk of XML becomes very important.

OK enough already!

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