[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)
Matt,
Precisely - and only if you do not have to exhaustively search all nodes
looking for possible matches....
eg how do you know when you are finished and there are not more matches
elsewhere?
DW
----- Original Message -----
From: "Matthew MacKenzie" <mattm@adobe.com>
To: "Duane Nickull" <dnickull@adobe.com>
Cc: "David RR Webber" <david@drrw.info>; "Stuhec, Gunther"
<gunther.stuhec@sap.com>; <michael.conroy@wanadoo.fr>; "Mary Kay Blantz"
<blantz@attglobal.net>; <MCRAWFORD@lmi.org>; <regrep@lists.oasis-open.org>
Sent: Monday, September 20, 2004 4:52 PM
Subject: Re: [regrep] Impact of ICG Adoption on CCRIM SC (Was:
[regrep]UN/CEFACT-ICG adopts freebXML Registry)
> Remember, simplicity does not necessarily yield performance. Shallow
> nesting only adds a performance benefit when you are always parsing
> using a DOM.
>
> On 20-Sep-04, at 4:50 PM, Duane Nickull wrote:
>
> > You could also use the Iterator() getNext() method to rip through
> > various attribute values until you find the match.
> >
> > Duane
> >
> > Duane Nickull wrote:
> >
> >> 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.
> >
>
>
> 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]