[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [codelist] Alternatives for new specifications of context
How about replacing Context/@context with Context/@scope ? I recommend sticking with the XPath syntax for elements vs. attributes. Cheers, Tony. ----- Original Message ----- From: G. Ken Holman <gkholman@CraneSoftwrights.com> To: Code List Representation TC <codelist@lists.oasis-open.org> Sent: Sat, 12 Jan 2008 18:55:48 +0000 (GMT) Subject: Re: [codelist] Alternatives for new specifications of context Sorry, I forgot two things: (1) If you have alternative suggestions, please do not hesitate to mention them, modifying the instance fragment accordingly. (2) I've contemplated replacing item= with two attributes that describe the item in detail. The three anticipated syntaxes for item= to specify the information item with the coded value are the following XPath patterns: elementName @attributeName attribute::attributeName This relies on an implementation analyzing the syntax to determine the item's name and type. Would the specification be improved by replacing item= with the following? itemName="qualified-name-goes-here" attribute="yes-or-no-default-no" Note that for qualified names the CVA file has to have the appropriate namespace prefixes declared in scope of the <Context> element. Please offer your comments on keeping the status quo for item= or changing it to the above or something better. Thanks! . . . . . . . . . Ken At 2008-01-12 12:00 -0600, G. Ken Holman wrote: >Hi folks, > >Okay, before I make my code changes I'd like to address Paul's two >concerns regarding duplicate element/attribute names, and two ways >to specify context. > >Here is the status quo, where the first is an attribute (the others >are elements)document-wide, the second is a union, the third is >typical, the fourth needs more specific context than the third, the >fifth is document-wide and a union: > >A: > <Contexts> > <Context item="@currencyID" values="currency"/> > <Context item="cbc:CountrySubentityCode" > context="cac:BuyerCustomerParty" > values="provinces states"/> > <Context item="cbc:CountrySubentityCode" > context="cac:SellerSupplierParty" > values="states"/> > <Context item="cbc:ID" xpath="cac:TaxCategory/cbc:ID" > values="tax-ids"/> > <Context item="cbc:PaymentMeansCode" > values="payments additional_payments"/> > </Contexts> > >Option B: - changing only the element names to avoid ambiguity: > > <Associations> > <Association item="@currencyID" values="currency"/> > <Association item="cbc:CountrySubentityCode" > context="cac:BuyerCustomerParty" > values="provinces states"/> > <Association item="cbc:CountrySubentityCode" > context="cac:SellerSupplierParty" > values="states"/> > <Association item="cbc:ID" xpath="cac:TaxCategory/cbc:ID" > values="tax-ids"/> > <Association item="cbc:PaymentMeansCode" > values="payments additional_payments"/> > </Associations> > >Option C: - removing context= (necessitating xpath= when not full >document context) and keeping <Context>: > > <Contexts> > <Context item="@currencyID" values="currency"/> > <Context item="cbc:CountrySubentityCode" > xpath="cac:BuyerCustomerParty//cbc:CountrySubentityCode" > values="provinces states"/> > <Context item="cbc:CountrySubentityCode" > xpath="cac:SellerSupplierParty//cbc:CountrySubentityCode" > values="states"/> > <Context item="cbc:ID" xpath="cac:TaxCategory/cbc:ID" > values="tax-ids"/> > <Context item="cbc:PaymentMeansCode" > values="payments additional_payments"/> > </Contexts> > >To recap the need for item=, recall that an application needs to >know the name of the focus information item and whether or not it is >an attribute. This cannot easily be distilled from the XPath >address in the event the XPath address has predicates or multiple >steps. One of the reasons I came up with context= was to avoid >having to enter the focus item's name twice, for fear that it left >open the opportunity for typographical errors (which is still a risk >for xpath= but that would be used far less than context=). > >My personal preference is A, then B, then C. > >Can I get feedback on this as soon as possible, please, so that I >can finish up the documentation? > >Thanks! > >. . . . . . . . . . . . Ken -- Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008 World-wide corporate, govt. & user group XML, XSL and UBL training RSS feeds: publicly-available developer resources and training G. Ken Holman mailto:gkholman@CraneSoftwrights.com Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (F:-0995) Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/o/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php Anthony B. Coates Senior Partner Miley Watts LLP Experts In Data UK: +44 (20) 8816 7700, US: +1 (239) 344 7700 Mobile/Cell: +44 (79) 0543 9026 Data standards participant: genericode, ISO 20022 (ISO 15022 XML), UN/CEFACT, MDDL, FpML, UBL. http://www.mileywatts.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]