Comments on: Thinking about structure

By: Len Bullard

Len Bullard — Mon, 12 Mar 2007 12:07:05 +0000

Actually you will be better off separating your 2D and 3D data for reasons that don’t become apparent without trying that. There is a reason that 3D languages provide 2D layers. Flattening data at the source doesn’t change that. Like David, I spent more time working with SQL when working on production systems and grew to appreciate clean comma-delimited ASCII unless I wasn’t the generating source.

That said, David gets it exactly right: the expressiveness of the structure has to match the complexity of the information, something that can be expressed in path metrics, not to be described here. JSON is a low cost alternative. That’s fine. One thing years of markup experience taught me was to recant the wall-to-wall markup advocacy. It’s wrong. Can it all be wrangled in under the InfoSet? To be demonstrated by someone with more time and need to do that.

By: pwb

pwb — Sat, 03 Mar 2007 06:09:40 +0000

The problem with XML is that it encourages unnecesary data complexity. At the end of the day, data ends up needing to be representable in 2D and 3D so it’s not wise to design such complex structures. The biggest databases in the world still use flat files after all.

By: David Carver

David Carver — Mon, 29 Jan 2007 20:26:09 +0000

The whole JSON/XML debate is less scarey to me then seeing the above markup out in the real world. The sad thing here is that too many webservice XML ends up looking like the above because of the reliance on code generators instead of data architects to construct the XML. The prevelance of the above markup is still scary for systems that need expandability.

By: Qea

Qea — Mon, 29 Jan 2007 16:48:31 +0000

(names
(Saddam (Hussein) male)
(Al (Unser) Jr. male)
(Don Alonso (Quixote) de la Mancha male))

By: Dave Newton

Dave Newton — Mon, 29 Jan 2007 14:04:36 +0000

Why not just have a sequence that defines the order of the names? This way it can be customised on a per-object basis if necessary:

{”names!”: [
{"name-order": ["honorific", "given-name", "middle-name", "surname"],
“given-name”: “Anna”,
“middle-name”: “Maria”,
“surname”: “Mozart”,
“honorific”: “Dr.”}]}

While I generally shudder at mixing semantics with data, I’m not so sure I care in this case.

By: david

david — Mon, 29 Jan 2007 13:09:49 +0000

Thanks, Jonathan. My main point — to both the JSON and XML communities — is that if the information structure is simple, the XML markup or JSON representation can both be simple, and if the information structure is complex, the XML markup or JSON representation will both end up being more complex.

It’s misleading to argue that JSON is better because it’s simpler, or that XML is better because it’s more expressive, because there’s practically no difference on either count. It just happens that XML is generally used in situations where the information is more elaborate than a simple data structure, or, more importantly, in situations where you cannot constrain how the formats are actually used (one person might index the information, one might publish it, one might build a web app around it, etc.). JSON can work there too, but when it does, it will end up looking a lot like the XML. For the simple, RPC-like data structures that are currently JSON’s domain, XML can just as easily look a lot like JSON. I’ve made some changes to the posting along these lines.

By: Jonathan Buchanan

Jonathan Buchanan — Mon, 29 Jan 2007 10:08:43 +0000

Have you thought about how the JSON formats you’re proposing would actually be used?

e.g. the proposed “surname-after-given-names” property would never, ever be necessary, as you’d be doing something like this when actually using the data:

person.given-name + ” ” + person.surname

It seems to me like you’re thinking too much about representing the data in a way which is somehow equivalent with the XML, and not enough about how the data structures defined in your JSON (”That is trickier to dump straight into a data structure” - JSON *is* your data structure) will actually be used - in which case, an object for each name with properties for each section of the name really is a natural and intuitive way to represent the information.

In this case, all you’d really need to do would be to add prefix, and postfix properties to the format Douglas Crockford proposed in his blog post.

By: Martin

Martin — Mon, 29 Jan 2007 09:33:22 +0000

John: but there you let application knowledge slip into the data structure. Didn’t we all agree that is a bad idea? And you didn’t even specify secondary and tertiary sort keys, and maybe the collation to use …

By: Martins Notepad » Blog Archive » Markups raison d’être

Martins Notepad » Blog Archive » Markups raison d’être — Mon, 29 Jan 2007 09:31:06 +0000

[...] Megginson posted a follow up on his earlier take on JSON, which contains an excellent example/explanation on the advantages of [...]

By: John Cowan

John Cowan — Mon, 29 Jan 2007 08:18:01 +0000

Yeah, really what you need is “full name” (display name) and “sort name”. In general, you get the right answer most of the time if you mark up the primary sort key of the name, thus:

[name]John [sort]Cowan[/sort][/name]

[name][sort]Szilard[/sort] Leo[/name]

[name][sort]Mao[/sort] Zedong[/name]

[name][sort]Sukarno[/sort][/name]

[name]Vicente [sort]Fox[/sort] Quesada[/name]

[name]Alexis de [sort]Tocqueville[/sort][/name]

[name]Charles [sort]de Gaulle[/sort][/name]

[name]Henry [sort]Ford[/sort] II[/name]

[name][sort]Elizabeth II[/sort][/name]