Мысли по поводу структуры XML

← →
Галинка (2008-06-26 15:26) [0]

Собственно появилась мысля, сделать сохранение скрипта в таком вот формате. Появилась она во многом, благодаря требованию читабельности. Теперь вот обдумывается вопросик: хранить ли нужные параметру в тексте (1) узла, или в аттрибутах (2). Два примера:

1.
<Script>
<Command>
<Action>send</Action>
<Parameter>2#3030303ett</Parameter>
</Command>
<Command>
<Action>checkCursor</Action>
<Parameter>2408</Parameter>
</Command>
</Script>

2.
<Script>
<Command Action="send" Parameter="2#3030303ett" </Command>
<Command Action="checkCursor" Parameter="2408" </Command>
</Script>

Что кроме компактности дают аттрибуты? Понижают "глубину" вложений? Легчи распарсить узел с аттрибутами, чем с вложенными нодами?

← →
Поросенок Винни-Пух © (2008-06-26 15:31) [1]

так выглядит поиск узла с атрибутами. Это наглядно и читабельно:

"/Script/Command[@Action="send"]"

А если данные в тексте узла?

← →
Галинка (2008-06-26 15:34) [2]

+1 за атрибуты.

Еще какие мысли?

← →
Dennis I. Komarov © (2008-06-26 15:38) [3]

+1 за атрибуты по логике: параметры принадлежат действию, у них разный иерархический уровень. В (1) они на одном.

ЗЫ Выразился как смог :)

← →
Ega23 © (2008-06-26 15:39) [4]

Не дай бог " встретится...

← →
Dennis I. Komarov © (2008-06-26 15:41) [5]

> [4] Ega23 © (26.06.08 15:39)

&....;

← →
Поросенок Винни-Пух © (2008-06-26 15:43) [6]

В общем все станет ясно как только начнешь писать код ищущий то что надо. Тот, что будет проще тот и скажет что лучше.

← →
Ega23 © (2008-06-26 15:45) [7]

> &....;

да-да, и парсить это...

← →
Поросенок Винни-Пух © (2008-06-26 15:46) [8]

а зачем это парсить?

← →
Dennis I. Komarov © (2008-06-26 15:51) [9]

> [7] Ega23 © (26.06.08 15:45)

ну так жизнь веселая штука

← →
b z (2008-06-26 15:57) [10]

Мой вариант:
<Script>
<Command Action="send"><Parameter Value="2#3030303ett" /></Command>
<Command Action="checkCursor"><Parameter Value="2408" /></Command>
</Script>

← →
Галинка (2008-06-26 16:05) [11]

> Ega23 © (26.06.08 15:39) [4]
>
> Dennis I. Komarov © (26.06.08 15:41) [5]
>

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

← →
antonn © (2008-06-26 16:25) [12]

> Не дай бог " встретится...

addslashes, stripslashes :)

← →
Ega23 © (2008-06-26 16:28) [13]

Минусы:
1. Слишком избыточен
2. Здоровый по размеру, бо всё суть строка
3. Не везде есть DOM.

Плюсы:
1. x-path
2. Можно редактировать в любом текстовом редакторе
3. Почти везде есть DOM. :)

← →
Галинка (2008-06-26 16:36) [14]

Ega23 © (26.06.08 16:28) [13]

это ты сейчас о чем? ))) Если о применении хмл-а вообще, то это уже не обсуждается. Обсуджается только структура.

Да и еще, может релевантно. Запускаться вся эта байда будет из командной строки. Типа:

testkasse sales.xml

Если при анализу файла будут обнаружены ошибки, тест просто не пойдет. (Тончее это задумка такая)

← →
Ломброзо © (2008-06-26 16:37) [15]

Парсинг XML-я вручную - это вообще прошлый век. Все нормальные платформы уже давно предоставляют инфраструктуру для автоматической сериализации и десериализации кортежей объектов в- и из XML. Пометил что надо атрибутами - и вуаля. А сериализатор, ориентируясь на метаданные, сам решает, что писать в атрибуты XML, а что в узлы.

← →
Ломброзо © (2008-06-26 16:40) [16]

> Если при анализу файла будут обнаружены ошибки
Структурный анализ файла можно возложить на реализованные практически во всех современных парсерах валидаторы соответствия XML некоей схеме (DTD, XSD и т.п.)

← →
Галинка (2008-06-26 16:47) [17]

Ломброзо © (26.06.08 16:37) [15]

копаю вроде в этом направлении. Пока то, что делает XmlSerializer по-умолчанию не удовлетворяет. Скажи куда копать глубже? И про валидацию тоже.

← →
Галинка (2008-06-26 16:54) [18]

Ломброзо, посмотрела про сериализацию классов. Но проблема пока видится в том, что мне так и так придется распарсивать строки, которые в ListBox находятся. Так что придется всеж таки ручками наверное. Или как ты считаешь?

← →
Ломброзо © (2008-06-26 16:56) [19]

System.Xml.Serialization, XmlAttributeAttribute, XmlElementAttribute
System.Xml.Schema

← →
Галинка (2008-06-26 17:03) [20]

Ломброзо © (26.06.08 16:56) [19]

Именно это и читаю. Но там применительно, как ты совершенно справедливо заметил, к кортежам объектов. А у меня оди единственный объект - ListBox. Его строки - это строки нашего скрипта, которые и требуется по возможности читабельно, сериализовать в хмл.

← →
Ломброзо © (2008-06-26 17:05) [21]

А обернуть строку скрипта в некий сериализуемый в XML класс, переопределить ему метод ToString() и запихать коллекцию экземпляров этого класса в ListBox разве сложно? :) Перед сохранением нужно всего-то выгрести эти объекты в любую коллекцию или массив - и получим сериализуемую коллекцию объектов.

← →
Alkid (2008-06-26 17:06) [22]

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

← →
Поросенок Винни-Пух © (2008-06-26 17:09) [23]

Видимо фаст репорт дурные люди написали

← →
Галинка (2008-06-26 17:14) [24]

Ломброзо © (26.06.08 17:05) [21]

посмотрела проект. Это оказывается и правда объекты класса t_action и в проекте они собраны в список List<t_action> Liste = new List<t_action>(); А в листбоксе отображаются только как строки. Это самое действие имеет type и text. Я как-то попала не глядя, только назвала это Action и Parameter соответственно. Теперь только осталось сириализовать этот список с нужным набором аттрибутов? Я правильно поняла?

← →
Галинка (2008-06-26 17:15) [25]

Alkid (26.06.08 17:06) [22]

ну кому как. Просто это наиболее репрезентативная из привычных форма представления информации.

← →
Ломброзо © (2008-06-26 17:17) [26]

Галинка (26.06.08 17:14) [24]

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

← →
VirEx © (2008-06-26 19:09) [27]

<Command Action="send" Parameter="2#3030303ett"> </Command>
лишнее, можно так:
<Command Action="send" Parameter="2#3030303ett" />

← →
Галинка (2008-06-26 19:19) [28]

обрадовали сейчас. Нада на жабе теперь делать (((

← →
Dummy (2008-06-26 19:40) [29]

> Собственно появилась мысля, сделать сохранение скрипта в
> таком вот формате. Появилась она во многом, благодаря требованию
> читабельности. Теперь вот обдумывается вопросик: хранить
> ли нужные параметру в тексте (1) узла, или в аттрибутах
> (2). Два примера:

Велосипед изобретаем? SyncML вам в помощь.

По существу - упаси Боже с таким работать. Это ж застрелиться можно.

> Галинка

Я когда то делал подобное, был выбор XML или нет. Решил делать без XML. Для таких простых вещей он только помеха. Реплики выглядили так:

Action: ActionType<cr><lf>
Param1: Value1<cr><lf>
Param1: Value1<cr><lf>
Param1: Value1<cr><lf>
Param1: Value1<cr><lf>
ActionID: UniqueID<cr><lf><cr><lf>

В эту структуру можно уложить в общем то любую информацию, в том числе и бинарную, при желании. Вложеннности нет, но мне она и не нужна была.

впринципе если настроек немного, можно напряч саму дельфю для настроек:
1. сделать TCantainer с паблишед свойствами Name, Descr, Script
2.
//важные процедуры для сохранения protected procedure GetChildren(Proc: TGetChildProc; Root: TComponent); override; procedure SetParentComponent(Value: TComponent); override; public procedure SaveContainer(FileName: string; Encrypt: Boolean); virtual; procedure LoadContainer(FileName: string; Encrypt: Boolean); virtual; procedure TContainer.GetChildren(Proc: TGetChildProc; Root: TComponent); var I: Integer; OwnedComponent: TComponent; begin inherited GetChildren(Proc, Root); for I := 0 to ComponentCount - 1 do begin OwnedComponent := Components[I]; if not OwnedComponent.HasParent then Proc(OwnedComponent); end; end; procedure TInventory.SetParentComponent(Value: TComponent); begin inherited; end; procedure TContainer.LoadContainer(FileName: string; Encrypt: Boolean); var FileStream: TFileStream; MemStream: TMemoryStream; EncryptStream: TMemoryStream; begin if not fileexists(Filename) then exit; DestroyComponents; //óäàëÿåì ñòàðü¸ Classes.RegisterClass(TContainer); //áàçîâûé êëàññ ðåãèñòðèðóåì-ñ //если будешь делать на основе контейнера компоненты, то здесь их регистрируй FileStream := TFileStream.Create(FileName, 0); MemStream := TMemoryStream.Create; try if (not Encrypt) or (not Assigned(EncrypteProc)) then ObjectTextToBinary(FileStream, MemStream) else begin EncryptStream := TMemoryStream.Create; EncrypteProc(FileStream, EncryptStream, aDecrypt); ObjectTextToBinary(EncryptStream, MemStream); EncryptStream.Free; end; MemStream.Position := 0; MemStream.ReadComponent(self); finally MemStream.Free; FileStream.Free; end; end; procedure TContainer.SaveContainer(FileName: string; Encrypt: Boolean); var FileStream: TFileStream; MemStream: TMemoryStream; EncryptStream: TMemoryStream; begin FileStream := TFileStream.Create(FileName, fmCreate); MemStream := TMemoryStream.Create; try MemStream.WriteComponent(self); MemStream.Position := 0; if (not Encrypt) or (not Assigned(EncrypteProc)) then ObjectBinaryToText(MemStream, FileStream) else begin EncryptStream := TMemoryStream.Create; ObjectBinaryToText(MemStream, EncryptStream); EncrypteProc(EncryptStream, FileStream, aEncrypt); EncryptStream.Free; end; finally MemStream.Free; FileStream.Free; end; end;

Encrypt потри, эт я для шифрации типа делал :)

вот пример сохранёнки (TInventory, THost, TItem это TContainer со своими уникльными паблишед свойствами)

object TInventory
User = "User"
Password = "pass"
Limit = 0
object THost
Name = "tsclient"
Caption = "tsclient"
object TItem
Name = "Win32_Processor"
Caption = "sdf"
object TValue
Name = "Name"
Caption = "gggsdfg"
end
object TValue
Name = "Caption"
Caption = "sdfsdfasdf"
end
...........................
end
end
end

блин, сколько ошибок наделал :(

вот как пример:

TScript=class(TContainer)
TCommand=class(TContainer)
...

в коде:
s:=TScript.create(nil);
s.Name:="скрипты";
c:=TCommand.create(s);
c.Action:="act1";
c.Parameter:="aaa";
//можно добавить такую функцию
witn s.NewCommand do
Action:="act2";
Parameter:="bbb";
end;
//или так
s.NewCommand("act3","ccc");
s.SaveContainer("Scripts.txt");

s.LoadContainer("Scripts1.txt");
for I := 0 to s.ComponentCount - 1 do
c:=s.Components[I];

← →
_ShaggyDoc (2008-06-27 06:48) [34]

Если вернуться к исходному вопросу - хранение в тексте или в атрибутах. Единых правил нет, каждый устанавливает сам. У меня лично сотни XML и данные, в основном записаны именно в атрибутах. Но это такая у меня специфика назначения XML.

Тем не менее, есть мнение, что в атрибутах надо хранить информацию, не являющуюся частью самих данных (метаданные), а в тексте - сами данные.

Считается что с атрибутами есть проблемы:

а) атрибуты, в отличие от дочерних элементов, не могут содержать больше одного значения

б) при внесении изменений атрибуты тяжело расширяются

в) атрибутами нельзя описать структуры

г) программам тяжело работать с атрибутами

д) атрибуты не легко проконтролировать на соответствие единому ОТД — определению типа документа, устанавливающему валидность того или иного XML документа.

Я лично с этими проблемами не столкнулся. Возможно пока. Лично мне пока в атрибутах мешает необходимость хранить в значениях текст с кавычками. Это такая специфика - я труда включаю программные макросы, у которых встречаются двойные кавычки. Следовательно, значение атрибута должно быть обрамлено одинарными кавычками. Но "шибко умные" парсеры, наподобие MSXML непременно заменяют все кавычки на двойные, чего мне не надо. Решил вопрос альтернативным парсером, который никакой отсебятины не вносит, да и работает раз в 10 быстрее.

Но, в данном случае, правильнее было бы вынести эти данные в текст. Сдерживает пока то, что мне надо непременно отображать элементы XML визуально в дереве, а лишние - не нужны. Но это решаемо. Только руки не доходят переделать.

Преимущество XML в структурировании информации. Скрипт — последовательный набор команд. Нафига козе баян?

← →
Галинка (2008-06-27 10:02) [36]

_ShaggyDoc (27.06.08 06:48) [34]

спасибо за обстоятельный ответ. Поробовала вчера XMLSerializer. Он поступает так же. Т.е. если делать сериализацию и десериализацию, то в принципе лучше брать родную структуру. Чтобы не делать свой парсер.

ПыСы: эта байда должна быть на жаве и вроде под линухом.

ну в джаве IZEN спец...

← →
Галинка (2008-06-27 10:54) [38]

надо его позвать )))

> Поросенок Винни-Пух © (26.06.08 15:31) [1]
> так выглядит поиск узла с атрибутами. Это наглядно и читабельно:
> "/Script/Command[@Action="send"]"А если данные в тексте
> узла?

То тогда

/Script/Command[Action="send"]

Ничуть не менее наглядно и читабельно.

Мысли по поводу структуры XML Найти похожие ветки