Issue 284: Malformed PropertyName (issues) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: It is not believed that the spec ever defines what a "malformed" PropertyName is. The closest definition is in para on page 26, section 5.1.1.2 and is not much help Resolution: Revised Text: Actions taken: October 19, 1996: received issue Discussion: End of Annotations:===== >From mail Sat Oct 19 16:43 EDT 1996 X-Sender: vinoski@pop-e3.ch.apollo.hp.com Date: Sat, 19 Oct 1996 16:38:11 -0400 To: issues@omg.org, orbos@omg.org From: Steve Vinoski Subject: trading spec issues Content-Length: 1293 * I have similar questions about property names. There is an IllegalPropertyName exception defined in the CosTrading module, and a number of trader and service type repository operations are supposed to check for "malformed" property names. But like ServiceTypeName, PropertyName is defined as an Istring, and I don't believe the spec ever defines what a "malformed" PropertyName is (the closest definition I could find was in the second paragraph on page 26, section 5.1.1.2, and it's not much help). Should PropertyName also be a typedef of CORBA::Identifier, with the same character set restrictions and case sensitivity characteristics as mentioned above? thanks, --steve > * I have similar questions about property names. There is an > IllegalPropertyName exception defined in the CosTrading module, and a > number of trader and service type repository operations are supposed > to check for "malformed" property names. But like ServiceTypeName, > PropertyName is defined as an Istring, and I don't believe the spec > ever defines what a "malformed" PropertyName is (the closest > definition I could find was in the second paragraph on page 26, > section 5.1.1.2, and it's not much help). Should PropertyName also be > a typedef of CORBA::Identifier, with the same character set > restrictions and case sensitivity characteristics as mentioned above? This is easier. In Annex B, the BNF for a constraint effectively limits a property name (called Ident in the BNF) to being: := := /* */ | where The previous BNF has been complete up to the non-terminals , , , , and . For a particular character set, one must define the characters which make up these character classes. Each character set which the trading service is to support must define these character classes. This annex defines these character classes for the ASCII character set. := := | | _ [underscore!] is the set of alphabetic characters [A-Za-z] is the set of digits [0-9] is the set of ASCII characters that are not , , or So, a property name using ASCII is: [A-Za-z][A-Za-z0-9_]* and any extended character set must define what additional characters (if any) can be used at the start or in the rest of a property name. For the sake of the parsers, I hope nobody decides to use characters like "+" or "-" which are used elsewhere in the grammar. Property names are case sensitive (since nothing says they aren't). Do any other Trader submitters want to express an alternative view on any of these issues? Kerry ============================================================================= Dr Kerry Raymond, Architecture Unit Leader E-mail: kerry@dstc.edu.au CRC for Distributed Systems Technology Phone: +61 7 3365 4310 University of Queensland 4072 Australia Fax: +61 7 3365 4311 =========================================== WWW: http://www.dstc.edu.au/kerry Date: Wed, 21 Mar 2001 10:57:02 +1000 (EST) From: Michi Henning To: Juergen Boldt cc: issues@emerald.omg.org Subject: Re: Lost issues In-Reply-To: <4.2.0.58.20010320104951.00a86ca0@emerald.omg.org> Message-ID: Organization: Object Oriented Concepts - An IONA Company MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: :BJe9a1K!!,[8e9=SL!! On Tue, 20 Mar 2001, Juergen Boldt wrote: > Hello all, > > URL http://cgi.omg.org/issues/issues.html > contains links to issues which have not been assigned to R/FTFs > because of > a couple of reasons: > ..to name a few... > a) The RTF/FTF has expired and should be re-chartered > b) The RTF/FTF has expired and will never be re-chartered again > (several > reasons why are possible) > c) I just didn't know what RTF/FTF would be responsible for an issue > submitted.. > d) There appear to be no RTFs for most of the CORBAservices > e) Nobody knew about this issues archive > > With your help some of those issues could be resolved (by assigning > some of > those issues to active RTFs/FTFs or by rechartering some of the > expired > RTFs...) Here are some proposals: Issue 184: Close no change. I don't understand the question Issue 468: Close. The issue is empty. Issue 493: Close no change. It doesn't because the submitters decided that it wouldn't. Issue 498: From what I can recall, this refers to name equivalence in the Naming Service. INS has cleaned this, so close it. Issue 961: Move to http://cgi.omg.org/issues/event-rtf.html Issue 2347: Close. This was fixed by INS. Issue 2972: Move to http::/cgi.omg.org/issues/relationship-rtf.html Issue 3003: Close. Issue 3271: Close no change. Historically, iterators in the various specs are a total mess, and all of them, without exception, get it wrong :-( I'm afraid we have to live with the resulting inconsistencies. Issue 4216: Should probably be reassigned to Core RTF? Issues 284, 546, 547, 548, 549, 550, 558, 559, 560, 561, 562, 4225: We need a trader RTF for those. The remaining open issues also will require formation of RTFs. Cheers, Michi. -- Michi Henning +61 7 3324 9633 Object Oriented Concepts - An IONA Company +61 4 1118 2700 (mobile) Suite 4, 8 Martha St +61 7 3324 9799 (fax) Camp Hill 4152 michi.henning@iona.com Brisbane, AUSTRALIA http://www.ooc.com.au/staff/michi