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!


<Quote1>
<dw> ??? Now I'm confused - we're creating XML for UML models? </dw>
</Quote1>

No - we're creating an XML representation (with a minimal amount
represented in the existing RIM) of the Core Components specification
metadata defined in Section 7.

<Quote2>
why would we want to store the other binary goup - since we can't do
anything with that meaningful!!!
</Quote2>

There is nothing stopping someone from registering a UML model as an
Extrinsic object in the registry as it exists today. So it's not a case
of us "wanting" to store one. I think it would be good for registry
users to associate the UML and XML representations of their Core
Components using the registry association mechanism.

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

I think we're going in circles here between early 2003 and now. Back
around February, we had a long string of discussions in which all agreed
that the best approach was an XML serialization (you were one of the
main proponents of that approach). Have you changed your perspective?
How are registry users going to assemble schemas from Core Components if
they are not stored and maintained in XML format? 

>> They don't - that's our job

<Quote4>
<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.
</Quote4>

<Quote5>
>> Yes - and again, that is our mission.

<dw>And to get the requirements for that serialization</dw>
</Quote5>

Again, our requirements are the CCTS spec, Section 7.

<Quote6>
>> 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.....
</Quote6>

All very good points. They should be tackled within another initiative,
as our initiative is scoped to the CCTS spec, Section 7.

Joe

David RR Webber - XML ebusiness wrote:
> 
> 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>
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard


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