[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
Serm', Yes - OK - we're all on the same page here then. I just find it disconcerting when the real name is some 20 or 30 bytes long and the 'short hand' reference to it is just a mere 128 bytes long! Thanks, DW ----- Original Message ----- From: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov> To: <ebxml-bp@lists.oasis-open.org> Sent: Wednesday, November 26, 2003 12:13 PM Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idandname issue > Dave, > > But the users need not see the GUID when working with a modelling tool, do > they? I think what Sacha and Dale suggest is that both 'ID' and 'name' > attributes still be there but only the ID is used for referencing. > > - serm > > ----- Original Message ----- > From: "David RR Webber" <david@drrw.info> > To: "Dale Moberg" <dmoberg@cyclonecommerce.com>; "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:55 AM > 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]