- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Thu, 19 Jan 2012 12:42:22 +0800
- To: <public-linked-json@w3.org>
> The fix only worked because the input is being ignored by the current
> processor. The turtle serializer simply works on the output from the
> processor. The processor itself doesn't handle this syntax and would
> have to be changed, which is more complex.
Oh OK, I see.
> The complexities include, at least, changing the expansion algorithm so
> that an object (instead of a string) is used for all plain literals
Why? We could also define it so that it replaces those { @value: "xx" }
objects with plain strings.
> and changing the compaction algorithm so that objects containing only
> @value are converted to strings.
Yes, and I think (thought?) that that would be as trivial as the fix for the
Turtle output was.
> These changes can be made, but understand that if we support this
> syntax
> it isn't simply that we're handling a corner-case where some people
> might use this instead of the simpler "string for plain literals"
> syntax. Rather, it should be the official "expanded form" syntax for
> plain literals.
Again, why do we have to do that?
> Otherwise we'll be introducing inconsistency where there
> wasn't any before. Unless I'm mistaken, this will also be the first
> example of a "built-in" difference between compact form and expanded
> form, where the @context doesn't specify how the syntax is different,
> it
> is just "known" that compact form uses strings for plain literals and
> expanded form uses objects with a @value property.
Well, the output is also different if there's a type coercion. Changing the
value from a plain string to an object in the extended form.
--
Markus Lanthaler
@markuslanthaler
Received on Thursday, 19 January 2012 04:43:04 UTC