[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-ICGadopts freebXML Registry)
Duane,
This is not an elements v attributes holy war.
It's about understanding when and how to leverage each - and the
business use cases that we need to ensure work.
If I take a typical OAGi BOD or a UBL transaction with say 150 unique
business elements in it - and look to make individual
queries against those - in your attribute based method - if I want to
check say 5 properties I'm making 150 x 5 queries
via http-binding. Can I say that I suspect this is not a good thing?
In the alternative approach - I'm making at most
150 queries. There are other strategies with sub-assemblies and in-line
semantics and smart rule inferencing that when
you have a CAM template as well can get this down toward 50 or less.
DW
Duane Nickull wrote:
> Because it is unique - once you have found "the one" you can stop
> searching. One has to consider the methodology of the access, not just
> the raw code.
>
> exit();
>
> I think you will find that the way we laid it out is a compromise, but
> is the best way until the exact nature of the requirements can be
> validated against a critical mass adoption. I challenge anyone to
> find a better way. If there is such a solution, I am very open to
> changing the spec. Keep in mind that the requirements document is
> also available for download from Kavi.
>
> We shouldn't get bogged down too much in the elements vs. attributes
> holy war until the real life adoption is better understood.
>
> Duane
>
> David RR Webber wrote:
>
>> 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]