Re: Образцы для распознавания ХМЛ-я - Философия программирования

Здравствуйте, VladD2, Вы писали:

VD>Возможно в качестве паттернов можно было использовать сам ХМЛ, например:
VD>

VD>match (someXml)
VD>{
VD>  | xml <#
VD>    <Item PartNumber=$partNum>
VD>      <ProductName>$name</ProductName>
VD>      <Quantity>$(qty : int)</Quantity>
VD>      <USPrice>$(price : double)</USPrice>
VD>    </Item> #> when partNum == x => Используем name, qty и price
VD>  ...
VD>

VD>Но встает вопрос как быть со списками элементов (когда подэлементов большее одного) и вообще семантику придется продумывать по полной программе.

VD>Может быть уже что-то подобное есть?

Есть, в Scala например:
Herding XML in Scala

и http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf стр. 123

Здравствуйте, VladD2, Вы писали:

VD>Можно придумать что-то более удобное нежели XPath?

Посмотри еще тут http://d.plaindoux.free.fr/ocaml-xml/index.html
Паттерн матчинг XML для OCaml, сделан как расширение языка на camlp4.

Описание синтаксиса:
http://d.plaindoux.free.fr/ocaml-xml/overview.html

Примеры:
http://d.plaindoux.free.fr/ocaml-xml/tutorial.html
http://d.plaindoux.free.fr/ocaml-xml/examples.html

Здравствуйте, VladD2, Вы писали:

VD>Тут вот какая закавыка. Что XPath, что CSS selectors — это языки задающие условия поиска, а у паттерн-матчинга это не единственная задача. Паттерн-матчинг кроме этого еще представляет средство декомпозиции структур данных (в нашем случае ХМЛ-я, точнее того формата в котором ХМЛ представляется внутри памяти).
[...]
VD>Может быть уже что-то подобное есть?

CDuce?

Здравствуйте, Кэр, Вы писали:

Кэр>Я что-то пропустил?

CSS selectors имеют значительно более простой синтаксис. В случае встраивания в язык в виде match() например
это плюс. И опять же если говорить про встраиваемость то полный набор фич XPath никому не нужен (в контексте данного обсуждения).
Что-то явно придется выкидывать. И моя пятая точка мне говорит что в конце концов все сведется к набору фич CSS selectors.
Всякие там expressions значительно эффективнее делать в host language например. А тогда зачем XPath?

Ну и потом... XPath это про XML только. CSS selectors же в принципе расширяемые, например список :runtime-flags .

Скажем for(var in $$(link[href]:visited)) может быть применима к живому дереву объектов (скажем XAML) и
для получения значения runtime флага :visited вызвать visited {get ... } property.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>CSS selectors вестимо.
CS>>Здесь вот список наиболее популярных конструкций.

VD>Тут вот какая закавыка. Что XPath, что CSS selectors — это языки задающие условия поиска, а у паттерн-матчинга это не единственная задача. Паттерн-матчинг кроме этого еще представляет средство декомпозиции структур данных (в нашем случае ХМЛ-я, точнее того формата в котором ХМЛ представляется внутри памяти).

VD>И тут я не вижу как CSS selectors или XPath могут помочь в данном случае.

VD>Возможно в качестве паттернов можно было использовать сам ХМЛ, например:
VD>

VD>match (someXml)
VD>{
VD>  | xml <#
VD>    <Item PartNumber=$partNum>
VD>      <ProductName>$name</ProductName>
VD>      <Quantity>$(qty : int)</Quantity>
VD>      <USPrice>$(price : double)</USPrice>
VD>    </Item> #> when partNum == x => Используем name, qty и price
VD>  ...
VD>

VD>Но встает вопрос как быть со списками элементов (когда подэлементов большее одного) и вообще семантику придется продумывать по полной программе.

Как-то все это нетривиально. Т.е. вероятность [толкового] использования этого дела крайне низка.

В реалии чего-то такого вот:

var item = $(item[PartNumber={x}]);
try {
  var name = item.$(ProductName).text;
  var qty = item.$(Quantity).text.toInteger();
  var price = item.$(USPrice).text.toFloat();
  ... Используем name, qty и price ...
} catch(e) {}

вполне себе достаточно. По эффективности — то же самое. Зато не надо лишних абстракций, ни в runtime ни в компиляторе.
И вычислительная сложность предсказуема. CSS selectors имеют сложность O(N*D) — N — количесство DOM элементов, D — глубина дерева.

Всем привет!

Вопрос следующий. Можно ли придумать некий формат образцов (паттернов) для разбора (декомпозиции) ХМЛ лучший чем XPath?

Суть такая. Предположим что нам нужно разобрать ХМЛ-файл в некотором языке программирования. В этом языке сопоставление с образцом (ну, или просто switch, для тех кто не знаком с этой техникой) которое позволяет в качестве образца использовать нечто что позволяет легко распознать фрагмент ХМЛ-я. Например, так:

match (someXmlDom)
{
  | //oprders/$order[@id=123] => WriteLine(order.Customer)
  ...
}

Можно придумать что-то более удобное нежели XPath?

Здравствуйте, VladD2, Вы писали:

VD>Вопрос следующий. Можно ли придумать некий формат образцов (паттернов) для разбора (декомпозиции) ХМЛ лучший чем XPath?

Лучший по каким признакам?

Linq2Xml, например, позволяет строить достаточные удобные запросы относительно типизированной модели, если XSD схема известна заранее. То что неудобно — по XSD схеме приходится генерить/обновлять C# классы несколько в стороне.

Если Nemerle сможет прожевывать схему XSD на лету и выдавать intellisense + проверку кейзов матчинга на лету по схеме во время компиляции — будет круто, че

Здравствуйте, VladD2, Вы писали:

VD>Всем привет!

VD>Вопрос следующий. Можно ли придумать некий формат образцов (паттернов) для разбора (декомпозиции) ХМЛ лучший чем XPath?

CSS selectors вестимо.
Здесь вот список наиболее популярных конструкций.

VD>Суть такая. Предположим что нам нужно разобрать ХМЛ-файл в некотором языке программирования. В этом языке сопоставление с образцом (ну, или просто switch, для тех кто не знаком с этой техникой) которое позволяет в качестве образца использовать нечто что позволяет легко распознать фрагмент ХМЛ-я. Например, так:
VD>

VD>match (someXmlDom)
VD>{
VD>  | //oprders/$order[@id=123] => WriteLine(order.Customer)
VD>  ...
VD>}
VD>

VD>Можно придумать что-то более удобное нежели XPath?

CSS selectors удобнее чем XPath (имхо).

например в tiscript (и соотв. в Sciter) можно писать так:

найти первый:

var el = $(orders>order[id=123]);

найти все c ID и распечатать их ID:

for( var el in $$(orders>order[id]) )
  stdout.println(el.attributes["id"]);

Здравствуйте, c-smile, Вы писали:

А это:

match (someXmlDom)
{
  | //oprders/$order[@id=123] => WriteLine(order.Customer)
  ...
}

записывается как:

if(someDomEl.$is(orders>order[id=123]))
   stdout.prinln(someDomEl);
else if( ...

Здравствуйте, c-smile, Вы писали:

VD>>

VD>>match (someXmlDom)
VD>>{
VD>>  | //oprders/$order[@id=123] => WriteLine(order.Customer)
VD>>  ...
VD>>}
VD>>

CS>найти первый:
CS>

CS>var el = $(orders>order[id=123]);
CS>

А где тут роковое отличие? В CSS Selector на несколько разделительных символов меньше, согласен. Но это скорее

чем

Я что-то пропустил?

Здравствуйте, c-smile, Вы писали:

CS>CSS selectors вестимо.
CS>Здесь вот список наиболее популярных конструкций.

Тут вот какая закавыка. Что XPath, что CSS selectors — это языки задающие условия поиска, а у паттерн-матчинга это не единственная задача. Паттерн-матчинг кроме этого еще представляет средство декомпозиции структур данных (в нашем случае ХМЛ-я, точнее того формата в котором ХМЛ представляется внутри памяти).

И тут я не вижу как CSS selectors или XPath могут помочь в данном случае.

Возможно в качестве паттернов можно было использовать сам ХМЛ, например:

match (someXml)
{
  | xml <#
    <Item PartNumber=$partNum>
      <ProductName>$name</ProductName>
      <Quantity>$(qty : int)</Quantity>
      <USPrice>$(price : double)</USPrice>
    </Item> #> when partNum == x => Используем name, qty и price
  ...

Но встает вопрос как быть со списками элементов (когда подэлементов большее одного) и вообще семантику придется продумывать по полной программе.

Может быть уже что-то подобное есть?

Здравствуйте, c-smile, Вы писали:

CS>Как-то все это нетривиально. Т.е. вероятность [толкового] использования этого дела крайне низка.

С чего же это?

CS>В реалии чего-то такого вот:

CS>

CS>var item = $(item[PartNumber={x}]);
CS>try {
CS>  var name = item.$(ProductName).text;
CS>  var qty = item.$(Quantity).text.toInteger();
CS>  var price = item.$(USPrice).text.toFloat();
CS>  ... Используем name, qty и price ...
CS>} catch(e) {}
CS>

Эта реалия похожа на грязь.

Здравствуйте, the_void, Вы писали:

_>CDuce?

Что-то сложновато выглядит.

Здравствуйте, z00n, Вы писали:

Z>Есть, в Scala например:
Z>Herding XML in Scala

Z>и http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf стр. 123

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

Здравствуйте, Кэр, Вы писали:

VD>>Вопрос следующий. Можно ли придумать некий формат образцов (паттернов) для разбора (декомпозиции) ХМЛ лучший чем XPath?

Кэр>Лучший по каким признакам?

По критерию удобства использования.

Кэр>Linq2Xml, например, позволяет строить достаточные удобные запросы относительно типизированной модели, если XSD схема известна заранее. То что неудобно — по XSD схеме приходится генерить/обновлять C# классы несколько в стороне.

Что-то я не слышал о том, что Linq to Xml использовал бы XSD. Можно ссылочку объясняющую о чем идет речь? Может речь о неком отдельном проекте?

Кэр>Если Nemerle сможет прожевывать схему XSD на лету и выдавать intellisense + проверку кейзов матчинга на лету по схеме во время компиляции — будет круто, че

Сделать то можно все что угодно. Вопрос только во времени которое нужно потратить и в конечном результате.

Собственно сейчас речь идет о совершенно ином. Видимо ты не знаком с тем, что такое сопоставление с образцом. Потому и говоришь о чем-то отвлеченном.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, the_void, Вы писали:

_>>CDuce?

VD>Что-то сложновато выглядит.

"Эта реалия похожа на грязь." да?

Здравствуйте, c-smile, Вы писали:

CS>"Эта реалия похожа на грязь." да?

Ага. Как-то все это нетривиально. Т.е. вероятность [толкового] использования этого дела крайне низка.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, z00n, Вы писали:

Z>>Есть, в Scala например:
Z>>Herding XML in Scala

Z>>и http://www.scala-lang.org/sites/default/files/linuxsoft_archives/docu/files/ScalaReference.pdf стр. 123

VD>Вот это ближе всего к тому что хотелось бы. Вот только там, как я понял, проблемы разбора последовательностей не решены. Или я что-то проглядел?

Я поцитирую "Programming in Scala":

An XML pattern looks just like an XML literal. The main difference is
that if you insert a {} escape, then the code inside the {} is not an expression
but a pattern. A pattern embedded in {} can use the full Scala pattern language,
including binding new variables, performing type tests, and ignoring
content using the _ and _* patterns.

You can match against a sequence of nodes instead of a single one. The pattern for “any
sequence” of XML nodes is written ‘_*’. Visually, this sequence looks like
the wildcard pattern (_) followed by a regex-style Kleene star (*).

def proc(node: scala.xml.Node): String = node match {
    case <a>{contents @ _*}</a> => "It's an a: "+ contents
    case <b>{contents @ _*}</b> => "It's a b: "+ contents
    case _ => "It's something else."
}

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, c-smile, Вы писали:

CS>>"Эта реалия похожа на грязь." да?

VD>Ага. Как-то все это нетривиально. Т.е. вероятность [толкового] использования этого дела крайне низка.

Ото ж.

Здравствуйте, z00n, Вы писали:

Z>

Z>def proc(node: scala.xml.Node): String = node match {
Z>    case <a>{contents @ _*}</a> => "It's an a: "+ contents
Z>    case <b>{contents @ _*}</b> => "It's a b: "+ contents
Z>    case _ => "It's something else."
Z>}
Z>

Я правильно понимаю, что "@" используется в скале для связывания имени с паттерном?

Здравствуйте, VladD2, Вы писали:

VD>Я правильно понимаю, что "@" используется в скале для связывания имени с паттерном?
Да, как в Хаскеле.

Здравствуйте, VladD2, Вы писали:

Кэр>>Лучший по каким признакам?
VD>По критерию удобства использования.

Офигительный критерий

Любой инструмент будучи заточен на удобство для решения одних задач оказывается неудобен для решения других задач. Не бывает просто абстрактного удобства.

Кэр>>Linq2Xml, например, позволяет строить достаточные удобные запросы относительно типизированной модели, если XSD схема известна заранее. То что неудобно — по XSD схеме приходится генерить/обновлять C# классы несколько в стороне.

VD>Что-то я не слышал о том, что Linq to Xml использовал бы XSD. Можно ссылочку объясняющую о чем идет речь? Может речь о неком отдельном проекте?

Да, ты прав. Это называется Linq2XSD. Я просто в блогах видел упоминание этой фичи:
http://blogs.msdn.com/b/xmlteam/archive/2006/11/27/typed-xml-programmer-welcome-to-linq.aspx
Сам проект:
http://linqtoxsd.codeplex.com/

Из беты они правда так и не вышли еще.

Кэр>>Если Nemerle сможет прожевывать схему XSD на лету и выдавать intellisense + проверку кейзов матчинга на лету по схеме во время компиляции — будет круто, че

VD>Сделать то можно все что угодно. Вопрос только во времени которое нужно потратить и в конечном результате.

Да я и не настаиваю

VD>Собственно сейчас речь идет о совершенно ином. Видимо ты не знаком с тем, что такое сопоставление с образцом. Потому и говоришь о чем-то отвлеченном.

Я говорю о том, чтобы в некоторых случах писать строго-типизированные паттерны. Но пусть будет, что я не знаком с паттерн-матчингом — я опять же не настаиваю

Здравствуйте, Кэр, Вы писали:

Кэр>Да, ты прав. Это называется Linq2XSD. Я просто в блогах видел упоминание этой фичи:
Кэр>http://blogs.msdn.com/b/xmlteam/archive/2006/11/27/typed-xml-programmer-welcome-to-linq.aspx
Кэр>Сам проект:
Кэр>http://linqtoxsd.codeplex.com/

Кэр>Из беты они правда так и не вышли еще.

Вот, кстати (уз извиняюсь за упоминание Немерла), но если бы эту фичу писали на Немерле, то она давно была бы зарелизена. Как раз для подобных задач макросы — это самое удобное средство реализации.

VD>>Собственно сейчас речь идет о совершенно ином. Видимо ты не знаком с тем, что такое сопоставление с образцом. Потому и говоришь о чем-то отвлеченном.

Кэр>Я говорю о том, чтобы в некоторых случах писать строго-типизированные паттерны. Но пусть будет, что я не знаком с паттерн-матчингом — я опять же не настаиваю

Кстати, очень советую познакомиться с паттерн-матчингом. Весьма интересная штука.

Здравствуйте, VladD2, Вы писали:

VD>Вот, кстати (уз извиняюсь за упоминание Немерла), но если бы эту фичу писали на Немерле, то она давно была бы зарелизена. Как раз для подобных задач макросы — это самое удобное средство реализации.

Когда, кстати, Немерле релизит первую версию? А то бету Linq2Xsd качать тоже можно и пользоваться. Просто статус у нее официальный бета.

VD>Кстати, очень советую познакомиться с паттерн-матчингом. Весьма интересная штука.

Я согласен интересная

Я только не понимаю, почему ты решил, что типизация в написании паттернов для матчинга означает, что я не понимаю паттерн-матчинг

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

Здравствуйте, Кэр, Вы писали:

Кэр>Когда, кстати, Немерле релизит первую версию? А то бету Linq2Xsd качать тоже можно и пользоваться. Просто статус у нее официальный бета.

Бэта 2 опубликована буквально только что. Изменений уже практически не будет. Теперь будут только вычищать баги которых и так не очень много. В основном баги сосредоточены в поддержке IDE. Так что на стабильность компилятора они не влияют. А релиз будет как только дочистим баги. Если все пойдет хорошо, то через месяц где-то.

VD>>Кстати, очень советую познакомиться с паттерн-матчингом. Весьма интересная штука.

Кэр>Я согласен интересная

Ты вроде бы сам сказал об этом.

Здравствуйте, VladD2, Вы писали:

VD>Бэта 2 опубликована буквально только что. Изменений уже практически не будет. Теперь будут только вычищать баги которых и так не очень много. В основном баги сосредоточены в поддержке IDE. Так что на стабильность компилятора они не влияют. А релиз будет как только дочистим баги. Если все пойдет хорошо, то через месяц где-то.

Это интересно.

VD>Ты вроде бы сам сказал об этом.

Я не стал тебе доказывать, что я знаю его, ибо смысла в этом мало

	От:	z00n
	Дата:	12.07.10 19:51
	Оценка:	46 (2)

	От:	FR
	Дата:	14.07.10 04:44
	Оценка:	46 (2)

	От:	the_void
	Дата:	12.07.10 22:20
	Оценка:	44 (1)

От:	c-smile	http://terrainformatica.com
Дата:	10.07.10 03:03
Оценка:	2 (1)

От:	c-smile	http://terrainformatica.com
Дата:	12.07.10 23:19
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	09.07.10 22:13
Оценка:

	От:	Кэр
	Дата:	23.07.10 15:20
	Оценка:

	От:	Кэр
	Дата:	23.07.10 15:39
	Оценка:

	От:	dilmah
	Дата:	23.07.10 15:41
	Оценка:

	От:	Кэр
	Дата:	23.07.10 15:52
	Оценка: