W3C home > Mailing lists > Public > public-linked-json@w3.org > January 2012

RE: json-ld.org playground updated

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Thu, 19 Jan 2012 12:42:22 +0800
To: <public-linked-json@w3.org>
Message-ID: <007301ccd664$be633c70$3b29b550$@lanthaler@gmx.net>
> 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
Received on Thursday, 19 January 2012 04:43:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:19 UTC