Правда исходя из моих задач, я поступил более кардинально - возможности удалить нет вообще. Не знаю насколько это будет адекватно в будущем, но вроде пока адекватно.
В RDF тоже прийдется. Потому что в начале разметки указывается к какому элементу относятся свойства.
В том-то вся и соль что не придется. Т.е. придется, конечно, но не пользователю. Эту работу берет на себя библиотека для обработки протокола.
В случае rdf значительно упрощается обработка связей - не надо доставать все по айдишникам из разных частей документа, как вы предлагаете, и склеивать их. К варианту с JSON это тоже относится.
Этот язык разметки изначально создавался чтобы описывать связи между различными объектами. И именно за счет этой его узкой по сравнению с xml нишей, который все-таки позиционируется, как язык для описания всего, работать с ним в условиях современного интернета получается удобнее.
Соглашусь.
Сейчас у нас особо выбора нет, а данная заметка - не более чем предположение о развитии.
С моей точки зрения я отчетливо вижу, что третья нотация несет в себе очень удобные идеи с лаконичным синтаксисом. Моя точка зрения основывается на моем опыте работы с DOM, где я начал применять нечто подобное, не успев ознакомится еще с RDF. (у меня оно как раз на JSON ездит, к слову).
При этом, если учесть, что это только самый верхний уровень RDF, то я уже сейчас читаю его спецификацию в поиске новых идей, которые можно применить на практике.
Это вы не улавливаете, я ошибаюсь, или у нас различная терминология?
Вложение в RDF логическое - да, есть. Но оно никак не связано с синтаксисом разметки.
Я могу указать атрибуты и свойства элемента, объявленного в начале документа, в средине (а в некоторых случаях вообще в другом документе) так, что это вообще не повлияет на выходную объектную модуль документа. Изменится только порядок ее генерации.
В XML, чтобы реализовать нечто подобное, потребуется дополнительно ухищряться, в связи с тем, что у элементов должен быть обязательный родительский элемент, описание элемента начинается с открывающего и заканчивается закрывающим тэгом - все что вне этой пары, к описанию элемента не имеет отношения (если искусственно вынести какие-то параметры в другой элемент, объединив их по айдишнику - это придется дополнительно обрабатывать).
ЗЫ я правильно понял что потоком вы предлагали парсить XML регулярными выражениями?
ничего не мешает. Более того, сейчас это единственный способ делать нечто подобное.
Только не в виде Json, а в виде JavaScript:
<script>
process({'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}});
process({'element_1':{'Title': 'Первый элемент'}});
</script>
нельзя... точнее смысла нет - описание каждого узла вложено внутрь тэга. Т.е. даже если иметь возможность разбора на лету, я получу всю информацию по элементу до того, как смогу сказать "ага, вот и сам элемент у нас получился". Я не могу оставить "на потом" самые тяжелые его части.
потом... парсить ХМЛ регулярными выражениями вместо DOM-a мне кажется некузявым. Или есть другие способы?
если бы оно у меня обрабатывалось, я бы не написал этот пост :)
Где-то в средине я упомянул что у меня работает нечто похожее по смыслу, но существенно отличное по синтаксису и форматам, скриптоподобие :)
готов поспорить... у меня есть подозрение, что баги в гаджетах будут не настолько фатальны, как кажется. Как минимум потому, что в отличие от того-же банковского софта, что может оказывать влияние на мировую экономику - десятки и сотни миллионов жизней людей, то встроенный гаджет, это все-таки персонализированный аппарат. Который, к тому-же, не влияет напрямую на жизнедеятельность организма, в отличие от кардиостимуляторов (наверное это будет самый известный встраиваемый гаджет).
У меня есть подозрение, что даже в случае перезагрузки нейро-интерфейса, будет ощущение тошноты и дезориентации в пространстве. Ну может еще нечто похожее на "ногу отсидел". Однако не более того. А в случае если сам по себе нейро-интерфейс будет делаться как сверх-надежное устройство, то баги в подключаемых к нему устройств будут влиять уже исключительно на наше восприятие и вызывать не более чем сейчас вызывает раздражение недоделанный софт.
ЗЫ да, я оптимист :)
ЗЫЫ я к тому что из-за незначительности последствий контроль за качеством врядли сильно увеличится.
Правда исходя из моих задач, я поступил более кардинально - возможности удалить нет вообще. Не знаю насколько это будет адекватно в будущем, но вроде пока адекватно.
не в своей есть другой специализированный формат. :)
В том-то вся и соль что не придется. Т.е. придется, конечно, но не пользователю. Эту работу берет на себя библиотека для обработки протокола.
В случае rdf значительно упрощается обработка связей - не надо доставать все по айдишникам из разных частей документа, как вы предлагаете, и склеивать их. К варианту с JSON это тоже относится.
Этот язык разметки изначально создавался чтобы описывать связи между различными объектами. И именно за счет этой его узкой по сравнению с xml нишей, который все-таки позиционируется, как язык для описания всего, работать с ним в условиях современного интернета получается удобнее.
Сейчас у нас особо выбора нет, а данная заметка - не более чем предположение о развитии.
С моей точки зрения я отчетливо вижу, что третья нотация несет в себе очень удобные идеи с лаконичным синтаксисом. Моя точка зрения основывается на моем опыте работы с DOM, где я начал применять нечто подобное, не успев ознакомится еще с RDF. (у меня оно как раз на JSON ездит, к слову).
При этом, если учесть, что это только самый верхний уровень RDF, то я уже сейчас читаю его спецификацию в поиске новых идей, которые можно применить на практике.
Вложение в RDF логическое - да, есть. Но оно никак не связано с синтаксисом разметки.
Я могу указать атрибуты и свойства элемента, объявленного в начале документа, в средине (а в некоторых случаях вообще в другом документе) так, что это вообще не повлияет на выходную объектную модуль документа. Изменится только порядок ее генерации.
В XML, чтобы реализовать нечто подобное, потребуется дополнительно ухищряться, в связи с тем, что у элементов должен быть обязательный родительский элемент, описание элемента начинается с открывающего и заканчивается закрывающим тэгом - все что вне этой пары, к описанию элемента не имеет отношения (если искусственно вынести какие-то параметры в другой элемент, объединив их по айдишнику - это придется дополнительно обрабатывать).
ЗЫ я правильно понял что потоком вы предлагали парсить XML регулярными выражениями?
Только не в виде Json, а в виде JavaScript:
<script>
process({'element_1':{'ID':1, 'Xcoord':100, 'Ycoord':100}});
process({'element_1':{'Title': 'Первый элемент'}});
</script>
потом... парсить ХМЛ регулярными выражениями вместо DOM-a мне кажется некузявым. Или есть другие способы?
Где-то в средине я упомянул что у меня работает нечто похожее по смыслу, но существенно отличное по синтаксису и форматам, скриптоподобие :)
У меня есть подозрение, что даже в случае перезагрузки нейро-интерфейса, будет ощущение тошноты и дезориентации в пространстве. Ну может еще нечто похожее на "ногу отсидел". Однако не более того. А в случае если сам по себе нейро-интерфейс будет делаться как сверх-надежное устройство, то баги в подключаемых к нему устройств будут влиять уже исключительно на наше восприятие и вызывать не более чем сейчас вызывает раздражение недоделанный софт.
ЗЫ да, я оптимист :)
ЗЫЫ я к тому что из-за незначительности последствий контроль за качеством врядли сильно увеличится.