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

Всем привет!

Вопрос следующий. Можно ли придумать некий формат образцов (паттернов) для разбора (декомпозиции) ХМЛ лучший чем 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 на несколько разделительных символов меньше, согласен. Но это скорее

чем

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

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

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

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.

Здравствуйте, 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
  ...

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

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

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

CDuce?

Здравствуйте, 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 — глубина дерева.

Здравствуйте, 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	www.nemerle.org
Дата:	09.07.10 22:13
Оценка:

	От:	Кэр
	Дата:	10.07.10 01:38
	Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	10.07.10 02:21
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	10.07.10 02:28
Оценка:

	От:	Кэр
	Дата:	10.07.10 02:32
	Оценка:

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

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

	От:	z00n
	Дата:	14.07.10 01:46
	Оценка:

	От:	z00n
	Дата:	14.07.10 03:07
	Оценка: