[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [Fwd: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencingwith id and name issue]
Hi Monica Comments SS:) On Fri, 2003-11-21 at 00:58, Monica J. Martin wrote: > Sacha, > This may answer some of your questions, if you look at one of the issues > discussed in the development of v1.1 (for example, see explanation on > page 71). In addition see: Page 86, 87 (for GUID and GUIDREF: All > elements are required to have GUID (instead of xs:ID) because of the > notion of includes and packages, which would lead to invalid XML > document if xs:ID and xs:IDREF were used. This result was part of the > discuss driven by the eBA (see reference below) and the need to globally > uniquely identify business documents (I've included a few snippets of > the discussion below). > > Finally, the eBusiness Architecture, draft document, also specifies that > the business process runtime expression should be globally unique and > "include references to which Registry can provide the correct metadata > about the Business Process Runtime Expression or instance thereof....." > (eBA, v0.83, page 34). > SS:) Thanks I really have to read up to 1.1 > Perhaps, some of the other technical folks can add more detail to > effectively answer your questions. Can you describe why you feel "having > both, the name AND ID, this invites to have logically invalid BPSS XML > instance documents"? OK. In BPSS XML Schema 1.01 the data type of the attribute businessDocument of the element DocumentEnvelope is "simply" a xsd:string, which can have any value. The businessDocumentIDRef on the other hand is a xsd:IDREF data type and "must" point to a xsd:ID attribute within the XML document. An attribute of type xsd:IDREF allows the parser to validate if the value given in businessDocumentIDRef is available within the XML document. The parser has no idea about businessDocument as it is "just" a string and that will always be valid. A real problem occurs if businessDocument and businessDocumentIDRef point to a different BusinessDocument, which hopefully does not happen but would still be a valid XML. Hope this describes why I feel it could introduce logically invalid (but XML valid) documents. Sacha <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> > ======================================================================================================= > <Snippet> > Comment from Anders Tell: > According to the UEB architecture v0.32, line 821-827 the parameters in > BPS document are to be considered as default values and a TPA may > override these. If the TPA does so the TPA values take precedence. > This indicates a need of being able to uniqually identify all or most > elements of BPSS documents such as BinaryCollaborations, Transitions, > Business states etc. I dont think the current spec contains such statement. > There are at least two ways to go. > 1. Add 'ID' identifiers to all specifications elements such as > adding/moving ID to BusinessState and adding ID to Transition. > > Resolution: *_RESOLVED_* > Check in specification for elements without identifiers - Name - > attribute with a type of ID, example. Didn't use the XML Schema ID type > because when you have a package, the IDs may not be unique. Explain ID > type must be unique within a given document. In addition, for packaging, > this could be handled with an include (see BPSS 1.01, line 1722, section > 8.1) that existed for the ProcessSpecification. Also see > ProcessSpecification in 1.05 (See Section 8.1.15). Package specified at > 8.1.19. Have a NAME with an associated NAME ID.......NAME within a > package (PIP ID in name field for RosettaNet ). > <Snippet> > > > > > > > > > > -------- Original Message -------- > Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with > id and name issue > Date: Thu, 20 Nov 2003 22:19:08 +0800 > From: Sacha Schlegel <sacha_oasis@schlegel.li> > To: ebxml-bp@lists.oasis-open.org > References: <1069336162.850.88.camel@gnaraloo.schlegel.li> > > > > 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 ------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]