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!


Great posting - all makes sense.  Can you please go have a look
at the XML in the following CEFACT document for me?

It's out at this link:


This was the "magic" that we built previously.  It got complicated
as it was trying to handle the assembly as well.  If you 'ignore' that
peice - and just look at the noun / codelist pieces - and assume
we'll handle the aggregation separately - and then compare this
to what you have done already with your CC/BIEs - I'd be
very interested in your feedback.

The synergy needed in my opinion is - cleverly leveraging the 
existing RIM plus good XML 'containers' for the atomic 
components of the vocabulary needs.

While I hate to go "backwards" at this - by looking at XML before
we get the requirements sets - I think in this case - its instructive 
to learn from what has gone before - so as we do not lock 
ourselves into a path that is potentially a cul-de-sac.

That's why I'm very reluctant to engineer something from UML
to Registry - where there is a "then a miracle happens" in 
between.  My sense is - if it were that easy - it would have been
done already - and things like xUML and iUML show us that
researchers are still trying to grapple with the fundamentals
there - not a place for the unwary to tread!

And that brings us back to having a clear and consistent
set of XML serialization that can be readily understood and
populated - not just from UML - but any open model environment
or dictionary.

Then as you mention there are 'little' details like being able
to have localization support built-in - key for Europe needs.

Thanks, DW.
Message text written by Diego Ballvé
David, you mentioned performance as an issue against using existing
registry constructs, due to traversing nodes and so on - and I can
tell you that I've experienced this issues in practice - but I believe
you would not be able to put all the information you need into a
single chunk of XML (when working with Core Components), unless the
registry would do some magic and combine all the parts you need into
this document and return it to you. I might be missing something, but
this is how I see it till now.


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