Arnaud Blandin wrote:
>Hi Brian,
>
>In the castor mapping XML Schema, name is of type 'ID' for class
>because this classname can be used elsewhere in the mapping to refer
>to the class. Indeed 'depends' and 'extends' are directly used to
>refer to a class whose mapping is defined in the mapping file.
>
And therein lies the problem, the 'name' attribute of a class element
is a Java type name. Java have inner classes which can have a '$' in
the name. The 'type' attribute of a relation field also is a java class
name, but the XSD doesn't allow a '$' in the name.
>
>Concerning NMTOKEN, I am not sure of which 'type' you are talking
>about?(what is the parent element?) but I can assure you that ID is not
>a super set of NMOTKEN, there is no relation between the two.
>
I'm speaking of the 'type' attribute in a 'field' element of a mapping.
My intention is not to depate the meaning of 'superset' and
'relationship' here, but NMTOKEN and ID clearly have some relationship
since they define patterns of matching characters. These sets clearly
have some form of intersection since a string like
'org.exolab.castor.Database' is allowed in both. My question is whether
the pattern set of ID fully contains the pattern set of NMToken.
However, I haven't looked at the spec so I didn't make the assumption
that they do and hence I didn't change the XSD. Are there cases of
NMTOKEN that are not in ID? If not then my statement was that one
should be able to change the XSD to declare 'type' as ID without
breaking any existing mapping definitions.
I have a patch for castor to properly handle inner classes with '$' in
them. It will work, but as the XSD stands today, one cannot have a
realtionship to an inner class. Make the call.
>
>Arnaud
>
>"This message is intended only for the use of the Addressee and may
>contain information that is PRIVILEGED and CONFIDENTIAL. If you are not
>the intended recipient, dissemination of this communication is
>prohibited. If you have received this communication in error, please
>erase all copies of the message and its attachments and notify us
>immediately."
>
>
>
>
>>-----Original Message-----
>>From: bikehead [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, September 17, 2002 5:46 PM
>>To: [EMAIL PROTECTED]
>>Subject: Re: [castor-dev] Using OQL with inner classes...
>>
>>Well I have a patch to allow inner class names in OQL names, but I
>>have
>>another issue that is more troublesome. So right now one can use an
>>inner class name in a mapping and in OQL, but one cannot use it in a
>>relationship. The reason is that the XSD for the mapping file
>>defines
>>'type' as NMTOKEN ', but the class 'name' is ID. These are actually
>>incompatable since NMTOKEN doesn't allow '$'. While I can change the
>>XSD to ID, I'm not sure of the full ramifications. I *think* it is
>>a
>>backward compatable change since it appears that ID containse
>>NMTOKEN
>>sets. Any thoughts?
>>
>>-Brian
>>
>>
>>Bruce Snyder wrote:
>>
>>
>>
>>>This one time, at band camp, bikehead said:
>>>
>>>b>I can't use db.load() because I want to iterate over every
>>>
>>>
>>persistent
>>
>>
>>>b>instance of a class and there doesn't seem to be any other way to
>>>
>>>
>>do
>>
>>
>>>b>this. db.load requires an identifier which I don't have.
>>>
>>>I see.
>>>
>>>b>I'm working on a fix for this in org.exolab.castor.jdo.oql.Parser
>>>
>>>
>>and
>>
>>
>>>b>ParserTreeWalker. It appears to be a simple case of getting the
>>>
>>>
>>parser
>>
>>
>>>b>and expression builder to recognize '$' as a valid delimiter in a
>>>b>iterator specification.
>>>
>>>This is exactly why I wanted the line numbers in the stack trace. I
>>>
>>>
>>know
>>
>>
>>>it's in the ParserTreeWalker somewhere. Eventually I'd like to
>>>
>>>
>>rework
>>
>>
>>>the OQL implementation to make use of ANTLR. It's modeled after
>>>
>>>
>>ANTLR,
>>
>>
>>>but when using ANTLR, a lot of the code can be generated during the
>>>build process. Makes for very easy changes to the implementation ;-
>>>
>>>
>>)
>>
>>
>>>Let me know if you create a patch for this issue.
>>>
>>>BTW, thanks for you hard work.
>>>
>>>Bruce
>>>
>>>
>>>
>>>
>>--
>> __o
>> _-\<,_ Brian
>>(_)/ (_) [EMAIL PROTECTED] x503
>>
>>
>>-----------------------------------------------------------
>>If you wish to unsubscribe from this mailing, send mail to
>>[EMAIL PROTECTED] with a subject of:
>> unsubscribe castor-dev
>>
>>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
>
--
__o
_-\<,_ Brian
(_)/ (_) [EMAIL PROTECTED] x503
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
