| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
Although the "verbatim" idea is nice and simple, more fine-grained control is
necessary since these features (relative URI preservation and blank node label
clash avoidance) are useful in different situations.
|
|
|
|
[WIP] Testing?
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
