ссылки внутри json cхемы для дедупликации кода

это уже клиентский код, сам введи какие-то идентификаторы и словарь идентификатор-объект, при распаковке объекта линкуй ссылками, сами ссылки ты никак не сохранишь, может есть что-то готовое, хре знает

синтаксис JSON - убог и не расширяем,

для реализации твоей задачи можно его расширить и потреять совместимость с парсерами или наваять костылики

{type:"link";path:"blah.some.prop"} 
{link:"blah.some.prop"} 
// и т.п.

обрабатывать ручками - в зависимости от способностей твоего парсера

что значит расширить руками, синтаксис хранит только скаляры, т.к. это литерал жаваскрипта по сути, то что описывает оп это уже протокол, идентификаторы и справочники

бгг ты сказал много умных слов но не в тему, расширить синтаксис можно так

{
  some:[1,2,3,4, {muhaha:"inlined obj"}],
  obj:this.some[4]
}

все просто и даже валидно с т.з. жабаскрипта (конечно eval не отработает, но синтаксис верный, да и парсер для такого сваять плевое дело), но как json - нихрена не валидно

Все кто здесь отписались по моему не поняли про что я говорил.
Есть Система валидации json — json schema (http://json-schema.org/)
Которая предоставляет описания т.н. ключевых слов, от которых отталкиваются уже парсеры этой схемы http://json-schema.org/implementations.html

Мой вопрос связан исключительно с возможностями этой самой схемы. Предусмотрены в ней внутренние ссылки на объекты или нет

да ты же днище, какое еще расширение синтаксиса, васек

не предусмотрены, потому что в жсон ты описываешь скаляры

я днище, какое еще расширение синтаксиса, васек

Так вот ты какой, погромиист в адидасах из пту.

Неверная информация. Всё там предусмотрено через #ref . Уже сам разобрался. Пример внизу

Нашел решение сам. Кому интересно, приведённая в топике схема упрощается через ссылки так:

{
	"$schema":"http://json-schema.org/draft-03/schema#",
	"type":"object",
	"properties":{
		"minsize":{
				"description":"bla-bla 1",
				"$ref": "#/definitions/defval"
		},
		"maxsize:"{
				"description":"bla-bla 2",
				"$ref": "#/definitions/defval"
		}

	},
	"definitions":{
		"defval":{
			"type":"array",
			"items":{
				"type":"object",
				"properties":{
					"id":{
						"type":"integer",
						"minimum":0
					},
					"name":{
						"type":"string"
					}
				}
			}
		}
	}
}

ты хотел сказать, авторы парсера который ты используешь придумали такую надстройку и реализовали ее?

ты хоть понимаешь что расширить синтаксис и влепить «this» в жсон файл это разные вещи? хорошо когда его разбирает полноценный жаваскрипт интерпретатор, но бывает иначе

вообще говоря, как мне кажется, сериализация ссылок, это в любом случае клиентский код. т.е. компитенция программиста и его прямая обязаность

академик subwoofer чтоб не падать в грязь лицом мог бы сейчас подтвердить свой треп делом и привести примеры сериализации ссылок на xml, например, как он вообще себе это представляет?

Я не понимаю о чём вы тут спорите, для xml уже давно есть стандартизированный валидатор схемы http://en.wikipedia.org/wiki/XML_Schema_(W3C)

Топик создавался с вопросом про подобный валидатор для json, уже описанный на ietf (http://tools.ietf.org/html/draft-zyp-json-schema-03) но пока ещё видимо не слишком широко известный.

Надо внимательнее тему читать, перед тем как отвечать

Ты лучше молчи, а то у тебя такая фееричная концентрация глупости и злобы что я рассеюсь 8)

да я тебя просто по диагонали прочитал поначалу, а потом уже и не тебе отвечал, про валиадторы знаю но ценности в них пока не видел

пацаны смотрите я расширил синтаксис жсон: «foo»: this

>>> JSON.parse("{\"a\":this}")

SyntaxError: JSON.parse: unexpected keyword

Ну что, еще попрыгаешь предо мной?

так этож ты писал что такое расширение синтаксиса предусмотрено, хватит толстить, иди уроки делай

Мой школьный товарищь, ты плохо у меня списывал, у меня нет слов «предусмотрено».

вот не нужно теперь морозится только, твои были слова this[4]? мы уже ждем от тебя «допиленого» и расширеного парсера, ты даже не хочешь понять что у литерала объекта нет контекста и указывать this не на что, точнее он указывает на контекст из которого вызван

мы уже ждем от тебя «допиленого» и расширеного парсера

Школьный друх, во первых мне странно что ту о себе во множественном числе, во вторых у тебя толи шизофрения толи еще какое болезние если ты думаешь что я тебе что-то обещал.

Вот, а с точки зрения написания парсера - проблем нет, но у меня уже есть такой парсер:

{
  "key1":java.awt.Dimension{
    width:10,
    height:20
  },
  "key2":java.awt.Dimension[10,20],
  "key3":${[0][0].width}
}

зачем мне твой убогий json?

ты не юли пожалуйста, ${[0][0]} тут не this[0][0], впрочем чем это отличается от варианта «словари-индексы» и на какое поле в даном случае указывает индекс [0][0] абсолютно не понятно. но учитывая как ты переходишь на личности еще со второго ответа, я, пожалуй, сольюсь :Р

${[0][0]} тут не this[0][0],

А это тут тебе не json

чем это отличается от варианта «словари-индексы» и на какое поле в даном случае указывает индекс [0][0] абсолютно не понятно

Тебе не понятно, парсеру понятно: на width:10, только это старая версия синтаксиса в новой ${[«key»].width} было бы, но сути не меняет