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

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

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