[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 idand name issue
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. - 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]