[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Options for BP Spec Schema issue (#76) regarding ID and IDREF s
As per the 2001-04-25 conference call, regarding Issue #76 the resolution is to adopt Option 5 which specifies the use of optional machine readable ID/IDREFs in addition to the required human readable name/references. I suggest that in addition to this approach we go a small step further and use XPath as the syntax for the reference. This follows ebXML guidelines to adopt existing W3C specifications where possible and avoids the need to define a custom naming scheme. The advantages to this approach are: - it uses existing W3C specification for XPath - tools will more readily be able to process XPath expressions rather than a custom naming scheme - it is still human readable by the developers coding the XML directly, since they understand XPath - developers using popular XML tools will be able to cut and past XPath expressions - we will not have to document the naming convention The disadvantage (less significant) are: - XPath is slightly less human readable than the custom naming scheme. Consider the following real world example: <Package name="OAGOrdering"> <BinaryCollaboration name="OrderCollaboration" nameID="b111"> <AuthorizedRole name="buyer" nameID="r222"/> <AuthorizedRole name="seller" nameID="r223"/> </BinaryCollaboration> </Package> <Package name="ebXMLOrdering"> <BinaryCollaboration name="OrderCollaboration" nameID="b112"> <AuthorizedRole name="buyer" nameID="r224"/> <AuthorizedRole name="seller" nameID="r225"/> </BinaryCollaboration> </Package> As currently defined in the spec the name attribute is not required to be unique, thus allowing reuse of the names Ordering and buyer. To specify the reference to the buyer AuthorizedRole for the element Performs: <!-the custom approach --> <Performs authorizedRole="/OAGOrdering/OrderingCollaboration/buyer"/> <!-the XPath approach --> <Performs authorizedRole='//Package[@name="OAGOrdering"]/BinaryCollaboration[@name="Or derCollaboration"]/AuthorizedRole[@name="buyer"]'/> <!-Combination approach --> <Performs authorizedRole="buyer" authorizedRoleIDRef="r222"/> It is not required to use the full path specification as shown above, other forms of XPath expressions could be used as long as they resolve to a single reference. For example if buyer was unique to the document then the XPath could have been: <Performs authorizedRole='//AuthorizedRole[@name="buyer"]'/> Relative paths are also allowed for example: <BusinessTransactionActivity fromAuthorizedRole='../ AuthorizedRole[@name="buyer"]' ... /> Regards, P.S. I hope to get the updated DTDs as per todays meeting out before tomorrow morning. ________________________________________________________________ Kurt Kanaskie Lucent Technologies kkanaskie@lucent.com (610) 778-1069 Note the new number! -----Original Message----- From: Kanaskie, Kurt A (Kurt) Sent: Thursday, April 19, 2001 4:46 PM To: ebxml-bp@lists.ebxml.org Cc: 'Karsten Riemer' Subject: Options for BP Spec Schema issue (#76) regarding ID and IDREFs << File: BP Spec Schema issue regarding ID and IDREFs (Issue #76).doc >> All, As per today's BP Meta Model call, please see attached Word document detailing the issue and possible options. Please feel free to add to the Pros and Cons of each option. Hopefully this will help us work through the issue and come to a resolution. <<BP Spec Schema issue regarding ID and IDREFs (Issue #76).doc>> Best Regards, ________________________________________________________________ Kurt Kanaskie Lucent Technologies kkanaskie@lucent.com (610) 778-1069 Note the new number!
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC