[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idandname issue
Dale, I just realized there's another little gotcha here. I kinda assumed in my build out that GUID is illustrative - and I've just been putting in a shorter unique ID value locally. Obviously if you are referencing say a CPA - then GUID is a good idea - however they are extremely user unfriendly (and large!) - so often you just need a simple short - object counter # say, or similar - that just saves using the text name as the cross-ref'. Similarly - just to re-interate - what I'm doing is very visual facing - so having both the name text and the ID value in the schema works for me - so the user can see the text whenever they need to sanity check it - instead of having to hunt the XML instance to find it... Horses for courses! Thanks, DW. ----- Original Message ----- From: "Dale Moberg" <dmoberg@cyclonecommerce.com> To: "Monica J. Martin" <Monica.Martin@Sun.COM>; "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> Cc: <ebxml-bp@lists.oasis-open.org> Sent: Wednesday, November 26, 2003 11:36 AM Subject: RE: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idandname issue Hi, I take Sacha's (and Serm's) point to be that: For the purpose of reference from one element to some other element, one GUIDREF to the referenced element's @nameId GUID value is sufficent to accomplish referential uniqueness in BPSS. I hope that is accurate; anyway, the point seems to be true. Because chasing the reference will also allow finding the @name string value, it is not necessary to store that value in some attribute of the element we are referring from. The repetition of the value is prone to error during edits when only the original element's @name string value is changed. The convenience of not needing to chase the reference to find the string value probably does not outweigh the risk of error (and pain of looking for back references whenever the @name string value gets changed). So I agree with Sacha and Serm on the convention of using the GUIDREF values for reference. References from CPA, however, are not numerous, and so I think the repetition there can be allowed. The overhead of loading the BPSS instance, parsing, and then chasing references to get the @name value would then be more sizable. And even if the BPSS instance changes, I think the CPA values should stay as agreed upon so that the Message Header does not have to be changed... Dale Moberg -----Original Message----- From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] Sent: Wednesday, November 26, 2003 8:28 AM To: Boonserm (Serm) Kulvatunyou Cc: ebxml-bp@lists.oasis-open.org Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idandname issue Importance: Low Boonserm (Serm) Kulvatunyou wrote: >I agree with Sacha that there should be only one reference. I was >struggled with that redundancy too. I think the flexibility and >redundancy should be the tool functionality (like what david explain >with visual script). It need not be captured in the schema. > > mm1: Thank you Serm and Sacha for the inputs, as this adds to the discussion we had in Monday's call. And too, we should keep in mind not to map to specific product tool functionality which is outside of the scope. >- serm > >----- Original Message ----- >From: "David RR Webber" <david@drrw.info> >To: "Sacha Schlegel" <sacha_oasis@schlegel.li> >Cc: <ebxml-bp@lists.oasis-open.org> >Sent: Friday, November 21, 2003 1:28 PM >Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idand >name issue > > > > >>Sacha, >> >>Looks good. The only reason I guess for the redundancy in the fromFoo >>and fromFooID is that it saves the lookup - and makes the human >>readability easier. I'm not complaining at that! >> >>On the name front you may have two partners in a collaboration - and >>you send each of them "Parts Order Confirm" but for one you >>use "schema-P1.xsd" and the other "schema-P1a.xsd". It's >>nice to have the flexiblity - even if you would discourage >>the practice. It's also nice from the point of view of >>having libraries of different pre-built document definitions, >>that you drag and drop in - and then maybe edit afterwards - >>and they can have same names while you figure out those >>edits. >> >>DW. >> >>Quoting Sacha Schlegel <sacha_oasis@schlegel.li>: >> >> >> >>>Hi David >>> >>>On Sat, 2003-11-22 at 01:45, David RR Webber wrote: >>> >>> >>>>Sacha, >>>> >>>>The way I've implemented this in VisualScript models is to use them >>>>as cross-referencing - assuming the name is the human friendly >>>>detail, and the ID is the shorthand notation for cross-referencing. >>>> >>>>So as you add business documents to your BPSS model >>>>then go over and start to add business steps - those documents show >>>>up as choices for the user to select >>>>in the step. Display the names as part of the choices, >>>>and then key off the IDs for the software. >>>> >>>>You can auto-generate IDs for the user if you do >>>>not want them to have to mess with those. >>>> >>>> >>>> >>>Makes sense so far. >>> >>>Its purely an XML style, I guess. No doubt the user should not deal >>>with IDs. Let me explain in an example: >>> >>><Sample> >>> <Foo name="MyFoo" ID="foo_id"/> >>> <Bar name="MyBar" ID="bar_id" fromFoo="ABC" fromFooID="foo_id"/> >>></Sample> >>> >>>I do not understand why Bar must have fromFoo AND fromFOOID. One is >>>redundant, I think. One is enough and the better one is fromFooID, >>>IMO. Using globally unique ID's is even better. >>> >>>If you have to present to the user what Bar references, then you can >>>get the name of Foo my searching for the ID of Foo. I think XML >>>Parsers and/or XPath treat IDs specially for validation and for >>>easy/quick search (actually not sure about this). Not a XML parser >>>handles GUID similarly to ID. I think it is rather XML style or there >>>are good reasons why to use both. >>> >>>I see the need to make sure that ID's and names dont clash when >>>importing/including other data or even that they have to be globally >>>unique and hence using GUID/GUIDREF. You then even can have something >>>like MD5 Checksums associated with XML elements with GUID so you >>>could check the integrity of an element by comparing the checksum... >>> >>> >>> >>>>It also allows you to have the same business document >>>>name - but say different schema or CAM templates >>>>associated with it - and the software is able to distinguish the >>>>references OK. >>>> >>>> >>>Sorry I dont get this one. Might be a different story. Having a XML >>>instance which is valid for different schemas? Never thought of >>>that... >>> >>>Thanks >>> >>>Sacha >>> >>> >>> >>> >>>>Does this make sense? >>>> >>>>Thanks, DW. >>>> >>>>----- Original Message ----- >>>>From: "Sacha Schlegel" <sacha_oasis@schlegel.li> >>>>To: <ebxml-bp@lists.oasis-open.org> >>>>Sent: Thursday, November 20, 2003 9:19 AM >>>>Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with >>>> >>>> >>>idand >>> >>> >>>>name issue >>>> >>>> >>>> >>>> >>>>>Hi bp group >>>>> >>>>>OK I have a sample of the name and ID issue: >>>>> >>>>><ProcessSpecification ...> >>>>> ... >>>>> <BusinessDocument name="ABC" nameID="ABC_ID"> >>>>> ... >>>>> ... >>>>> <BusinessTransaction name="Trans1" nameID="Trans1_ID"> >>>>> <RequestingBusinessActivity name="ReqBizA" nameID="ReqBizA_ID" >>>>> >>>>> >...> > > >>>>> <!-- here the BusinessDocument gets referenced --> >>>>> <!-----------------------------------------------> >>>>> <DocumentEnvelope businessDocument="ABC" >>>>>businessDocumentIDREF="ABC_ID" .../> >>>>> >>>>> >>>>> </RequestingBusinessAcitivty> >>>>> ... >>>>> </BusinessTransaction> >>>>> ... >>>>></ProcessSpecification> >>>>> >>>>> >>>>>I did not read up on any "How to engineer XML documents", or UBL's >>>>>"Rules how to write an XML Schema" ... >>>>> >>>>>Kind regards >>>>> >>>>>Sacha >>>>> >>>>>On Thu, 2003-11-20 at 21:49, Sacha Schlegel wrote: >>>>> >>>>> >>>>>>Hi bp group >>>>>> >>>>>>Studing the BPSS XML Schema from the "ebXML Business Process >>>>>>Specification Version 1.01" I came across the following issue: >>>>>> >>>>>>Whenever an element X references another element Y there is a) the >>>>>> >>>>>> >>>name >>> >>> >>>>>>(required) of element Y AND b) the ID (optional) of element Y >>>>>> >>>>>> >given as > > >>>>>>an attribute of the X element. >>>>>> >>>>>>Sample from 1.01 Appendix A: >>>>>> >>>>>>....actually the sample bpss of 1.01 does not use ID's at all but >>>>>> >>>>>> >only > > >>>>>>names... >>>>>> >>>>>>Looking at the 1.1 BPSS still the name attribute and the ID >>>>>> >>>>>> >attribute > > >>>>>>are in elements. >>>>>> >>>>>>To me, only the ID attribute makes sense as with the ID I can get >>>>>> >>>>>> >to > > >>>the >>> >>> >>>>>>name of the element. Or even having only one, the ID or the name. >>>>>> >>>>>> >>>Having >>> >>> >>>>>>both, the name AND ID, this invites to have logically invalid BPSS >>>>>> >>>>>> >XML > > >>>>>>instance documents. >>>>>> >>>>>>If this issue has been addressed in a post 1.01 version then >>>>>> >>>>>> >please > > >>>>>>ignore this email. >>>>>> >>>>>>Kind regards. >>>>>> >>>>>>Sacha >>>>>> >>>>>> >>>>>-- >>>>>------------------------------------------------ >>>>>Sacha Schlegel >>>>>------------------------------------------------ >>>>>4 Warwick Str, 6102 St. James, Perth, Australia >>>>>sacha@schlegel.li www.schlegel.li >>>>>public key: www.schlegel.li/sacha.gpg >>>>>------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>>!DSPAM:3fbe4f59101291758211259! >>>> >>>> >>>-- >>>------------------------------------------------ >>>Sacha Schlegel >>>------------------------------------------------ >>>4 Warwick Str, 6102 St. James, Perth, Australia >>>sacha@schlegel.li www.schlegel.li >>>public key: www.schlegel.li/sacha.gpg >>>------------------------------------------------ >>> >>> >>> >>> >>http://drrw.net >> >> >> >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]