I've checked a fix for this into the branch. I'll apply it to head later. Cheers,
On 22/11/2007, Pete Robbins <[EMAIL PROTECTED]> wrote: > I'll need to look into this. I can't find any restrictions in the spec > for characters in property names so I'm assuming NCName. So I think > your patch looks good. > > The usual place where hyphens in names become a problem is when > mapping to programming language label but that is something that code > gen should take care of. > > This will be an issue in the HEAD as well as the branch. > > Cheers, > > On 16/11/2007, Caroline Maynard <[EMAIL PROTECTED]> wrote: > > A PHP user is facing a problem using a schema which uses the - (hyphen) > > character in element names, as second or subsequent character. We thinks > > this is valid XML, according to > > http://www.w3.org/TR/REC-xml/#NT-NameChar, where the grammar is: > > > > [4] NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar > > | Extender > > [5] Name ::= (Letter | '_' | ':') (NameChar)* > > > > What's actually happening is that he's getting an SDO_PropertyNotFound > > exception when he tries to set the property. Within the PHP > > implementation, this is resolving to > > > > dop->set<Type>('element-name', value) > > > > which ends up at: > > > > void DataObjectImpl::setSDOValue(const SDOString& path, > > const SDOValue& sval, > > const SDOString& dataType) > > > > Practically the first thing that method does is to call stripPath(), > > which removes the hyphen from the element name - resulting in the > > exception later on. > > > > I tried this patch: > > ### Eclipse Workspace Patch 1.0 > > #P pecl-sdo-FULMAR > > Index: commonj/sdo/DataObjectImpl.cpp > > =================================================================== > > RCS file: /repository/pecl/sdo/commonj/sdo/DataObjectImpl.cpp,v > > retrieving revision 1.20 > > diff -u -r1.20 DataObjectImpl.cpp > > --- commonj/sdo/DataObjectImpl.cpp 24 Aug 2007 15:20:21 -0000 1.20 > > +++ commonj/sdo/DataObjectImpl.cpp 16 Nov 2007 19:10:23 -0000 > > @@ -951,7 +951,7 @@ > > ////////////////////////////////////////////////////////////////////// > > > > const char* DataObjectImpl::templateString = > > - " > > /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#"; > > + " > > /abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890=[]._#-"; > > > > char* DataObjectImpl::stripPath(const char* path) > > { > > > > which appears to fix the problem. But I expect you'll tell me there is > > more to it than that. I know there are existing issues about valid > > characters in XPaths. But it seems a shame to prevent this simple > > scenario from working because of Xpath. > > > > (NB we're still on the branch. I don't know if this also applies to the > > trunk code.) > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Pete > -- Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
