[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was:[regrep]UN/CEFACT-ICG adopts freebXML Registry)
IDREF faster? Maybe if the XML has been indexed first ....
Look, at the end of the day DOM/SAX...it doesn't matter. In a
massively scalable system we need to use indexing and caching to solve
performance problems. Don't get too bogged down on the attr vs element
debate.
-Matt
On 20-Sep-04, at 9:31 PM, 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. 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.
>
> 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. You can also use
> IDRefs to make it even faster against the structures.
>
> 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.
>
> DW.
>
> ----- Original Message -----
> From: "Duane Nickull" <dnickull@adobe.com>
> To: "David RR Webber" <david@drrw.info>
> Cc: <MCRAWFORD@lmi.org>; <regrep@lists.oasis-open.org>; "Mary Kay
> Blantz"
> <blantz@attglobal.net>; "Stuhec, Gunther" <gunther.stuhec@sap.com>;
> <michael.conroy@wanadoo.fr>
> Sent: Monday, September 20, 2004 4:02 PM
> Subject: Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was:
> [regrep]UN/CEFACT-ICG adopts freebXML Registry)
>
>
>> Performance has been studied exhaustively.
>>
>> It is far easier to iterate through second level elements in the DOM
>> matching attribute values that accessing a deeply nested element in a
>> DOM tree.
>>
>> //using jbuilder v 8
>>
>> String myValue =
>> toString(root.getChild("Properties).getAttributeValue("assertedBy"));
>>
>> if (myValue = myToken){
>> //do what you need to do here
>> }
>>
>> This is as simple and perfomance enhanced as it gets.
>>
>> Duane
>>
>> David RR Webber wrote:
>>
>>> Duane,
>>>
>>> We also need to consider performance issues.
>>>
>>> Before we pass something over to CEFACT that looks like a
>>> recommendation - we need to attach
>>> some caveats.
>>>
>>> I don't think they should look at this than anything more than some
>>> initial fact gathering.
>>>
>>> My concern is that engines need to be able to optimize retrieval -
>>> and
>>> certainly that is difficult if
>>> everything is attribute based. It makes it almost impossible to
>>> reference things by XPath to
>>> limit sections of the structure that may only be needed - especially
>>> thru a http-binding - which is
>>> obviously preferred for speed over SOAP requests.
>>>
>>> The i/o speed is going to be critical for the success of this - so we
>>> need to plan for that and
>>> develop accordingly.
>>>
>>> These are the kind of things we should be helping CEFACT with -
>>> before
>>> we jump ahead
>>> and recommend structures for storage....
>>>
>>> Thanks, DW
>>> ===============================================
>>>
>>> Duane Nickull wrote:
>>>
>>>> Kathryn:
>>>>
>>>> I have cc'd some of the UN/CEFACT folks. I will present this
>>>> document during our next telecon so we can kick off the process. I
>>>> would like to have the one review before we publich this. In the
>>>> meantime, I will retitle the document "Recommendations to UN/CEFACT
>>>> for the storage of Core Components and BIE's in an ebXML
>>>> Registry-Repository".
>>>> They will then be able to absorb whatever parts of it into their
>>>> work
>>>> they need to.
>>>>
>>>> Duane
>>>>
>>>> Breininger, Kathryn R wrote:
>>>>
>>>>> We can approve it as a committee approved document. Basic steps
>>>>> are:
>>>>>
>>>>> 1. Present the document at one of our telecons (just an
> overview/intro)
>>>>> 2. TC reviews for 2 weeks, sends comments
>>>>> 3. Comments are resolved
>>>>> 4. At the next telecon, TC agrees to vote on the document as a best
>>>>> practices paper
>>>>> 5. Two week ballot is set up by TC Chair for TC voting
>>>>> 6. If TC approves, the document becomes a TC approved document,
>>>>> and is
>>>>> posted for public view.
>>>>>
>>>>> Let me know when you feel it is ready to present and I will add it
>>>>> to
>>>>> the agenda.
>>>>>
>>>>> Thanks,
>>>>> Kathryn.
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Monday,
>>>>> September 20, 2004 8:49 AM
>>>>> Cc: regrep@lists.oasis-open.org
>>>>> Subject: Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was:
>>>>> [regrep]UN/CEFACT-ICG adopts freebXML Registry)
>>>>>
>>>>>
>>>>> I actually also suggested this to Mark Crawford and others when I
>>>>> was in
>>>>>
>>>>> DC. I think it makes sense.
>>>>>
>>>>> Before we do this, I would like to wrap the work up slightly. The
>>>>> easiest way to do this is to change the title to something like
>>>>> "Recommendations to UN/CEFACT for storage of Core Components in an
>>>>> ebXML
>>>>>
>>>>> Registry/Repository" and then approve it as a best practices
>>>>> document within the TC.
>>>>>
>>>>> I am not sure what process we, as a TC, need to go through to
>>>>> approve this as a non normative document.
>>>>>
>>>>> Kathryn?
>>>>>
>>>>> Duane
>>>>>
>>>>> Farrukh Najmi wrote:
>>>>>
>>>>>
>>>>>
>>>>>> One important thing I did not mention is that UN/CEFACT is now
>>>>>> doing
>>>>>> two things as part of their ICG Architecture:
>>>>>>
>>>>>> 1. Define a normative expression syntax in XML for Core Components
>>>>>>
>>>>>> 2. Define a normative mapping from CCTS Information Model to ebXML
>>>>>> Registry Information Model
>>>>>>
>>>>>> These were 2 important specification that SHOULD have been done by
>>>>>> CCTS but since they were not we chartered CCRIM SC to do these.
>>>>>> Now that UN/CEFACT teams are committed to doing this work I
>>>>>> propose
>>>>>> that the CCTS team donate their current work-in-progress as input
>>>>>> (along with any recommendations) to the UN/CEFACT ICG and CCTS
>>>>>> teams and recharter to become the liaison and consultant to those
>>>>>> teams as they define and finalize these two tasks.
>>>>>>
>>>>>> Duane and others colleagues. What do you think of this idea?
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> To unsubscribe from this mailing list (and be removed from the
>>>>> roster of
>>>>> the OASIS TC), go to
>>>>>
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/
> leave_workgr
>>>>>
>>>>> oup.php.
>>>>>
>>>>>
>>>>>
>>>>
>>>> To unsubscribe from this mailing list (and be removed from the
>>>> roster
>>>> of the OASIS TC), go to
>>>>
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/
> leave_workgroup.php.
>>>>
>>>>
>>>
>>>
>>>
>>> To unsubscribe from this mailing list (and be removed from the roster
>>> of the OASIS TC), go to
>>>
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/
> leave_workgroup.php.
>>>
>>>
>>
>> To unsubscribe from this mailing list (and be removed from the roster
>> of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/
> leave_workgroup.php.
>>
>>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster
> of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/
> leave_workgroup.php.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]