Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
This reduces the stack space requirements for every type statement, at the cost
of adding a bit of constant bloat for the node in documents that do not contain
it.
|
|
Though potentially useful, I don't think the complexity cost of the old
interface (both to the implementation and to the user) is worth it. A special
tool to transform blank node labels (for example with regular expressions)
would be a better approach to this if it's ever needed in the future.
|
|
|
|
This makes it explicit in the API where memory is allocated, and allows the
user to provide a custom allocator to avoid the use of the default system
allocator for whatever reason.
|
|
|
|
This expands relative and prefixed URIs in the reader on the stack, rather than
passing them to the caller to be dealt with. This pushes these context-full
forms to the edge of the system as much as possible to minimise the headaches
they can cause.
Towards having stricter guarantees about nodes and eliminating the CURIE node
type altogether.
|
|
Writing having side-effects seems questionable in general, and this prepares
things for expanding URIs in the reader.
|
|
[WIP] Command line option, move later?
This adds a reader flag and serdi option for extending a syntax with support
for SPARQL-like variables, for storing things like patterns or simple queries.
|
|
|
|
|
|
|
|
|
|
The idea here is to remove the burden of passing things around like stack
sizes (where most users don't care and will be happy with a reasonably large
default) and keeping the call sites to things like serd_reader_new() clean.
The cost is a bit more state, so it's both more powerful and more potentially
flaky, since changing the limits has action at a distance that isn't clear from
the call site. I think it's worth it for the cleaner API in the common case,
and the much better forward compatibility.
|
|
This makes plumbing easier since everything goes through the same "stream" and
only one callback is required to handling everything. It's also more easily
extensible in case more event types need to be added in the future.
|
|
|
|
|
|
|