You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It looks like my email client and the Markdown here on GitHub also have issues with this 😄
The buffer size is something that sax handles. The current buffer size seems like a good default though, but I would be open to providing a config option to increase this buffer size.
Sorry for this issue @rubensworks :-) According to the standards IRIs can have arbitrary length, so it would be great if the max. IRI length could be configured. Such very lengthy IRIs are used in practice...
I have another use case for this issue: some literals are inherently long. This includes literals that serialize geometries, e.g., Well-Known Text (WKT) shapes.
The attached file contains such a geometry serialization (the file had to be renamed from geo.rdf to geo.txt in order to be uploaded here).
^ When this data is parsed, the parse succeeds but the literal is only returned in part. This results in incorrect data: the literal does not encode a full WKT shape.
rubensworks
changed the title
Max buffer length exceeded when parsing longer IRIs
Max buffer length exceeded when parsing longer IRIs and literals
Dec 4, 2020
Observation
When parsing an RDF/XML file that contains a longer IRI (over 100K characters long), the parser emits the following error:
Expected
The parser to be able to handle IRIs of longer length.
Steps to reproduce
The text was updated successfully, but these errors were encountered: