OSLC API and character encoding
Hi,
I'm having some issues with importing artifacts from a spreadsheet using the OSLC API when "special" characters are in use. The standard DOORS Next import works fine, so I know this should work.
The character codes are 0x02F5 and 0x02F6 which represent MODIFIER LETTER MIDDLE DOUBLE GRAVE ACCENT and MODIFIER LETTER MIDDLE DOUBLE ACUTE ACCENT.
When these characters are present DOORS Next returns a forbidden error to the call.
Do I need to do special character encoding i.e ˵ for these characters?
Thanks,
Andy
|
Accepted answer
Ian Barnard (1.5k●6●13)
| answered Aug 25 '21, 12:31 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER I tried pasting smart quotes “hello” from Word into a DN artifact. When I get the RDF for that artifact using REST API, it appears as “hello” - I observe that the RDF doesn't specify an encoding so I assume the default would be UTF-8
So maybe you need to encode these unicode characters like that?
Ralph Schoon selected this answer as the correct answer
Comments Thanks Ian, I'll give that a try. So, I've added some code to encode in this way
Here is a snip of the content generated for primary text...
Technical Questions (“TQ”) shall be treated as ...
I get the exact same error (403) coming back from the server as if I hadn't escaped those characters
Ah - just noticed my webclient class has Windows-1252 set in it, which may be overriding what I'm setting. I'll look at changing that That was the issue. The .net class has an encoding attribute, so what ever I was specifying was being overridden by the class attribute. It's now successfully added the escaped content, so I'll try without, but confident that it will be ok now. Thanks again for your assistance, much appreciated. |
2 other answers
David Honey (1.4k●1●7)
| answered Aug 25 '21, 8:37 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Are you specifying the character set in your PUT or POST
Comments Ah, I've been specifying in the XML. Thanks, I'll give this a try I've set the post Content-Type to application/xml; charset=utf-8 but still the same error Since you provide pretty much no information beyond it is not working, I don't know how anyone should be able to help. You can try to create a requirement based on your display data and see if that even works.
Here is an example of a post that causes the error. I've had to strip most of it out to fit in the post.
If I remove The •, “ and ” characters the requirement is correctly created.
If I leave them in I get a forbidden error returned by the server.
I build the string in c# and pass it through an XML parser prior to the post, so I know that the xml is well formed.
...
<rm_jazz:primaryText rdf:parseType='Literal'>;
<div xmlns='http://www.w3.org/1999/xhtml' id='_Nf2cQJKNEd25PMUBGiN3Dw'>TECHNICAL REQUIREMENTS
Vendors shall adhere to the following instructions in responding to Section 5.1
• Technical Requirement (“TR”) ...
• Technical Questions (“TQ”) shall be treated as ...
• Vendors shall ensure ...
</div></rm_jazz:primaryText>
</oslc_rm:Requirement>
</rdf:RDF>
|
Ralph Schoon (61.8k●3●36●43)
| answered Aug 25 '21, 8:53 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER I'm having some issues with importing artifacts from a spreadsheet using the OSLC API when "special" characters are in use. The standard DOORS Next import works fine, so I know this should work. This would assume that the DOORS import uses OSLC, which is very certainly not the case. Even if it was using it does not mean that it would not have to encode data in certain cases.
Yes, you have to use encoding where this is required to adhere to the standards.
In OSLC, the URI, headers and body must be valid by the various standards. This might differ if you use rdf+xml or json. In XML characters like > or < are an issue for example.
Look into those standards to find out which characters are allowed and how to encode others. Look into the OSLC standard documents and the fundamental standards for HTML etc. for the URI's and headers.
Comments Thanks Ralph. I'm using CDATA tags but I guess it requirement more work than that. Worth mentioning that I'm running the xml I create through an xml parser and that doesn't have a problem with what I'm sending to the server, so I'm not violating the XML standards |