OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[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]


Sacha's example maybe shows why we should try to use the GUID/GUIDREF
technique consistently.

I had not noticed that the technique had not been employed consistently.

Monica, should this be an Issue, rather than a topic? 

I think we should flag it as something to fix.

Dale


> 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]