Core Data reads xml store value @ as @
There is an attribute in my Core Data document-based app whose string
value can legitimately be a single single utf8 0x20 space character,
@ . (It's a user-selectable delimiter.)
When I save a document with this attribute value, reading the XML
store file with BBEdit shows that it is a single space character, like
this:
attribute name=firstname type=string /attribute
But it shows up as an empty string in the user interface when my app
loads the document. I inserted a manually-coded getter and found that
it's coming out of the moc this way, although if I re-type it to
become a single space again, it comes out of the moc as expected, ,
until I close and re-open the document. Then it's back to an empty
string, .
This is easily reproducible in DepartmentAndEmployees sample project.
In the app Target, set the document Store Type to XML. Add an
employee, type in firstName , save, re-open, and the name is
changed to . Same thing if the name is more than one space, such as
. However, it does not trim whitespace; for example,
Jerry is read as expected, with spaces on each end.
Add this code [1] to the Employee implementation to see the primitive
value.
If you use the sqlite store, it behaves ^I^ expect, properly reading
the one-character string. Of course, my app will ship with the sqlite
store but I need to know which behavior is expected and which behavior
is a bug, or if it is expected that the xml behave differently than
the sqlite, why?
Thanks as always,
Jerry Krinock
[1]
- (NSString *)firstName {
NSString * tmpValue ;
[self willAccessValueForKey:@firstName];
tmpValue = [self primitiveFirstName];
NSLog(@primitive firstName = \%...@\, tmpValue) ;
[self didAccessValueForKey:@firstName];
return tmpValue;
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Core Data reads xml store value @ as @
On Feb 20, 2009, at 6:45 PM, Jerry Krinock wrote: There is an attribute in my Core Data document-based app whose string value can legitimately be a single single utf8 0x20 space character, @ . (It's a user-selectable delimiter.) When I save a document with this attribute value, reading the XML store file with BBEdit shows that it is a single space character, like this: attribute name=firstname type=string /attribute I'd file that as a bug. The XML above, while legal, will most likely always result in a value of attribute being an empty string. Whitespace is typically trimmed by XML parsers. e.g. if you had: attribute ...[NEW LINE] [TAB][SPACE][NEW_LINE] /attribute You'd typically still get an empty string. The solution is to wrap the value in a CDATA block. But, I'm not familiar enough with CoreDate to know if that is some setting somewhere or an API call you need to make. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Core Data reads xml store value @ as @
On 21. Feb 2009, at 01:51, Ricky Sharp wrote: On Feb 20, 2009, at 6:45 PM, Jerry Krinock wrote: There is an attribute in my Core Data document-based app whose string value can legitimately be a single single utf8 0x20 space character, @ . (It's a user-selectable delimiter.) When I save a document with this attribute value, reading the XML store file with BBEdit shows that it is a single space character, like this: attribute name=firstname type=string /attribute I'd file that as a bug. The XML above, while legal, will most likely always result in a value of attribute being an empty string. Whitespace is typically trimmed by XML parsers. e.g. if you had: attribute ...[NEW LINE] [TAB][SPACE][NEW_LINE] /attribute You'd typically still get an empty string. Not exactly. See this: http://www.w3.org/TR/REC-xml/ 2.10 White Space Handling In editing XML documents, it is often convenient to use white space (spaces, tabs, and blank lines) to set apart the markup for greater readability. Such white space is typically not intended for inclusion in the delivered version of the document. On the other hand, significant white space that should be preserved in the delivered version is common, for example in poetry and source code. An XML processor must always pass all characters in a document that are not markup through to the application. A validating XML processor must also inform the application which of these characters constitute white space appearing in element content. A special attribute named xml:space may be attached to an element to signal an intention that in that element, white space should be preserved by applications. In valid documents, this attribute, like any other, must be declared if it is used. When declared, it must be given as an enumerated type whose values are one or both of default and preserve. For example: !ATTLIST poem xml:space (default|preserve) 'preserve' !ATTLIST pre xml:space (preserve) #FIXED 'preserve' The value default signals that applications' default white-space processing modes are acceptable for this element; the value preserve indicates the intent that applications preserve all the white space. This declared intent is considered to apply to all elements within the content of the element where it is specified, unless overridden with another instance of the xml:space attribute. This specification does not give meaning to any value of xml:space other than default and preserve. It is an error for other values to be specified; the XML processor may report the error or may recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values. The root element of any document is considered to have signaled no intentions as regards application space handling, unless it provides a value for this attribute or the attribute is declared with a default value. Klaus ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
