Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was: [regrep]UN/CEFACT-ICGadopts freebXML Registry)

[David RR Webber <david@drrw.info>]

Duane,

Parsing Error!

I was comparing the "make everything attributes approach" in your 
example - to the noun XSD that SCM is
working on where related content is organized with XPath parent nodes.. 

If you really think that once people are deploying their own CC 
registries - that the attribute mechanism is
not an open invitation to them to add in their own extensions - you 
really are dreaming!   Every authority
out there will find a need to add their own - STEP, OAGi, X12, PIDX, 
HL7, DOD, GSA, the list goes on.
That is interoperability hell - read W3C Schema XSD - where we are right 
now.

Question - why would I retrieve the German fragment - if I want French?
Question - why would I retrieve the text description notes if I'm 
checking the business rules?

You completely missed the point about the original intent - and Farrukhs 
stated path at the CEFACT meeting,
which remains to show how the native RIM can support the mechanisms CCTS 
needs in terms of associative
semantics and CC management - since the naitve RIM is highly optimized 
and should be preferred - rather
than tricks inside XML instances with attribute lists.

That mapping is crucial.  Once we have that - then we look at extending 
the needs to cover the physical
implementation layer - under that logical layer.  That is what the SCM 
noun XSD is focused on doing -
augmenting the CCTS/RIM mapping - but otherwise leveraging and relying 
on RIM to provide the core
associative heavy lifting for the CCTS model.

DW

Duane Nickull wrote:

> David:
>
> The attribute in this DOM tree is NOT deeply nested.  Please read the 
> document!!!   Comments inline:
>
> David RR Webber wrote:
>
>> Duane,
>>
>> Yeah - but - if the DOM tree is *not* deeply nested - then its faster 
>> via
>> the DOM tree than having to
>> crunch thru reams of attributes trying to find the one(s) that you 
>> want -
>> and that's the rub.
>>
> There are likely to be only 2-5 authorities who assert the CC 
> properties, therefore this argument is insignificant.
>
>>  Since its
>> not just one attirbute - but sets - and therefore you either have to 
>> return
>> the entire XML instance
>> to the requestor - or parse every attribute every time to find the 
>> complete
>> list of those needed.
>>  
>>
> Since you need the entire fragment anyways, once again this argument 
> is not valid.  JDOM build 4 ++ supports detach().
>
>> Any which way you slice it - that is much more resource intensive than a
>> well structured XML set
>> that organizes the components so you can descreetly retrieve just 
>> what you
>> want.
>>
> It is a well structured XML set that allows people to detach() only 
> the branch they need.  Please read the document.
>
>>   You can also use
>> IDRefs to make it even faster against the structures.
>>  
>>
> Only if the original ID is held into the DOM and also the entire IDREF 
> capable branch is also loaded.   Even then, it is arguably a minor 
> advantage (see XML-dev list from about 2001 Nov).
>
>> Not to mention that given the use cases you can return functional 
>> sets of
>> related information - just
>> like we currently do with RIM - but now this is noun-centric 
>> optimization.
>>  
>>
> ARGGhG!!!!  The only thing worse than loading one DOM tree into memory 
> would be to have to load two and also be dependent on a registry being 
> available AND incur network lag.  Combined, this would make it at 
> least 5 to 100 times slower.
>
> It is obvious by this comment that you have also not read the document.
> Please read it.
>
> Duane
>