[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Thanks Kenji "David RR Webber" <david@drrw.info> wrote=81F > 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=3D"MyFoo" ID=3D"foo_id"/> > > > >>> <Bar name=3D"MyBar" ID=3D"bar_id" fromFoo=3D"ABC" fromFooID=3D"= 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=3D"ABC" nameID=3D"ABC_ID"> > > > >>>>> ... > > > >>>>> ... > > > >>>>> <BusinessTransaction name=3D"Trans1" nameID=3D"Trans1_ID"> > > > >>>>> <RequestingBusinessActivity name=3D"ReqBizA" nameID=3D" ReqBizA_ID" > > > >>>>> > > > >>>>> > > > >...> > > > > > > > > > > > >>>>> <!-- here the BusinessDocument gets referenced --> > > > >>>>> <!-----------------------------------------------> > > > >>>>> <DocumentEnvelope businessDocument=3D"ABC" > > > >>>>>businessDocumentIDREF=3D"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]