Last modified: 2008-09-04 12:53:22 UTC
The values being returned for attributes in SMWSQLStore2 are being HTML-encoded (i.e., "<" is returned as "<"), which I don't think should happen (it doesn't happen for SMWSQLStore). I don't know what the ideal way to fix this is, but one way is to change line 174 of /includes/storage/SMW_SQLStore2.php from: $dv->setXSDValue($row->value, $row->unit); to: $dv->setXSDValue(html_entity_decode($row->value), $row->unit);
Strangely, the old SQLStore does not use any decoding either, so I do not see where the difference could come from. Normally, the "XSD value" should be encoded properly, and getWikiValue() or getShort*Text() should be used to retrieve the decoded version. If this fails, the afected datatype (string?) should be fixed.
Re-assign to extension developer for triage/comments.
I should clarify further: the store holds strings in the format given by the datavalue implementations. It does not do any encoding/decoding of its own. It just stores what it is given. So if anything changed, then hopefully not depending on the storage implementation alone. If there is a decoding/encoding problem anywhere, then this must be blamed on the affected datatype implementation (DV-class). The store does not return a value that is encoded in any way; it returns a objects. If you wish to display the value of such an object, you can use the get-methods of the datavalue and they will take care of all escaping/unescaping for you. This is where the encoding/decoding happens. So please specify which method of which datatype troubles you. I also do not actually see the problem yet (apparently you could just decode < by yourself). Is it that you want to distinguish between literal user input "<" and entity input "<"? But this distinction is fairly difficult to make anyway since such things may change even during parsing. So what is the problem?
No, problem, really; I somehow figured that this was incorrect behavior. I'm changing this to "invalid".
