OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[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)


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




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