NewContour

Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
XML-схемы » XML по земле
Страницы: 1
NewContour, Пожелание по NewContour в следующей схеме
Ольга, посмотрите на элемент NewContour. В SpecifyRelatedParcel, NewParcel и ExistParcel они по моему идентичны. Может имеет смысл сделать из него класс?
А еще я бы из Entity_Spatial сделал бы класс, но выкинул бы из него элемент Borders. А Borders добавил бы в наследуемом от Entity_Spatial классе, например ParcelEntity_Spatial. Тогда первый применялся бы для частей, а второй для з/у.
Типизация в STD_MP проведена не до конца, это да.
Я на это уже обращал внимание разработчиков в группе на фейсбуке. Мне ответили, эм..., расплывчато :)
Я бы предложил разместить схему на каком-нибудь SVN (или GitHub) совместными усилиями её причесать и выставить на суд разработчиков росреестра: понравится - возьмут, не понравится - ну значит не судьба :)
проще всего на Github.
ну что, кто сделает?
могу я сделать, попробовать....:idea:
но только ближе к концу недели, пока есть срочные задачи
Вы это серьезно? Разрабатывать схемы - вроде как непосредственная обязанность разработчиков схем, у них есть и рядовые разработчики, и главные специалисты по проектированию схем, и начальники отделов проектирования и разработки схем, и директора департаментов и отделов проектирования и разработки. Вроде как если все эти люди не смогли сделать что-то (раз возникла потребность в изменениях/улучшениях), и вы предлагаете им "давайте мы улучшим плоды ваших трудов и вы это возьмете, если понравится", то это вызывает некоторые сомнения? Типа вы приходите в булочную и говорите: "мне вкус ваших булочек не нравится, давайте я научу вас хлеб печь, сейчас рецепты в интернете опубликую - если понравится - будете печь более вкусный хлебушек!" :)

Может стоит лучше рассказать о тех практических случаях проведения кадастровых работ и оформления межевых планов, вместо которых за единственную основу для реализации схемы была взята теория из 412 приказа :)). То, что невозможно еще будет многие месяцы оформить с помощью этой версии схемы, пока, возможно, не станет возможным в следующей версии.
Константин, все методы хороши. Кто как может. Вы можете проанализировать спорные моменты при проведении кадастровых работ, так вперёд, отлично (нужна отдельная тема). А вот Артёму проще самому схему "слепить".
Цитата
Игорь Дегтярь пишет:
посмотрите на элемент NewContour. В SpecifyRelatedParcel, NewParcel
и ExistParcel они по моему идентичны. Может имеет смысл сделать из него
класс?
Здесь и в других подобных случаях не понятно, как лучше сделать, т.к. руководствовались следующим: есть контура – для них создается один тип, расширяемый в зависимости от того, какой контур – новый или уточняемый и т.д. Аналогично для частей. Изначально рассматривался такой вариант, как вы предлагаете, но от него отказались.
https://github.com/vvHedgehog/V04_STD_MP

Wellcome 8)
Артем, ваш шаблон для кадастрового номера ^\d{2}:\d{2}:\d{6,7} в XML не работает, вернее не считывается символ начала строки ^. Правильный шаблон будет без этого символа \d{2}:\d{2}:\d{6,7}.
По типу tClientAgent не вижу смысла добавления еще одного типа (вместо одного tFIO теперь два: tFIO и tClientAgent).
По поводу Entity_Spatial - вариант не плохой, но это решает не один разработчик, возможно, будем думать.
Дальше не смотрела, нет времени.
С уважением.
Вариант с частями ( tFormSubParcel, tExistSubParcel и т.д.) мы рассматривали ранее, до утверждения схемы, но отвергли. Получилось много типов, вместо одного (tSubParcel), но расширяемого. Я об этом уже писала. Но все же еще раз обсудим.
Марина Шайкина, спасибо что посмотрели, спасибо за отзывы.

Отвечу по ним:
1) шаблон кад номера: без символа ^ можно обойтись, видимо это зависит от движка RegExp, который используется при проверке схемы. - внесу изменения
2) tClientAgent - наследник tFIO, у которого появляется доп поле Appointment. Если наследника явно не выделить, то генератор классов создаст три похожих класса (извините за куски Делфового кода):

Код
  IXML_MPv4_STD_MP_Title_Client_Organization_Agent = interface(IXML_MPv4_TFIO)
    ['{0850AAEB-B824-4FE2-9C82-A289E5AF042A}']
    { Property Accessors }
    function Get_Appointment: AnsiString;
    procedure Set_Appointment(Value: AnsiString);
    { Methods & Properties }
    property Appointment: AnsiString read Get_Appointment write Set_Appointment;
  end;

  IXML_MPv4_STD_MP_Title_Client_Foreign_Organization_Agent = interface(IXML_MPv4_TFIO)
    ['{73DF6054-A073-4934-A675-8049A952F966}']
    { Property Accessors }
    function Get_Appointment: AnsiString;
    procedure Set_Appointment(Value: AnsiString);
    { Methods & Properties }
    property Appointment: AnsiString read Get_Appointment write Set_Appointment;
  end;

  IXML_MPv4_STD_MP_Title_Client_Governance_Agent = interface(IXML_MPv4_TFIO)
    ['{B6EE5C59-F39C-4D73-8CB0-803C1964E6AD}']
    { Property Accessors }
    function Get_Appointment: AnsiString;
    procedure Set_Appointment(Value: AnsiString);
    { Methods & Properties }
    property Appointment: AnsiString read Get_Appointment write Set_Appointment;
  end; 
и, соответственно, Organization, Foreign_Organization, Governance они ссылаются каждый на свой тип, а при вынесении tClientAgent благородно получается один класс, как который они все втроём ссылаются

Код
  IXML_MPv4_TClientAgent = interface(IXML_MPv4_TFIO)
    ['{9CD9866B-3EC3-4725-BDAA-C5484ECEBCEC}']
    { Property Accessors }
    function Get_Appointment: AnsiString;
    procedure Set_Appointment(Value: AnsiString);
    { Methods & Properties }
    property Appointment: AnsiString read Get_Appointment write Set_Appointment;
  end; 
3) хорошо, спасибо
4) по поводу типов tFormSubParcel, tExistSubParcel - это аналогично вынесению типа tClientAgent выше - они все наследники tSubParcel, если в tSubParcel что-то добавится, это естественно на tFormSubParcel, tExistSubParcel отразится, поэтому, конечно, tSubParcel уже стоит менять с оглядкой.
Плюс в вынесении типов в том, что если мы меняем что-то у tFormSubParcel, то это "отражается" на все сущности использующие этот класс.
яркий пример : http://forum-rosreestr.ru/forum25/topic298/ если бы был вынесен тип tCustomSpecifyParcel, то просто бы в одном месте вносились изменения и такого вопроса просто бы не было.

На гитхабе проект публичный, вы тоже можете его менять.
также там можно вести дискуссию (я думаю, что не всем на этом форуме будет интересны куски кода :))
для примера я выложил классы которые получались из xsd до рефакторинга и после (на Delphi и C#) - там наглядно видно из-за чего многие сторонние разработчики хотят более строгой типизации в xsd.
Изменено: Артем Попов - 20.08.2013 17:13:28
Цитата
Артем Попов пишет:
если бы был вынесен тип tCustomSpecifyParcel
Это конечно наша ошибка. Мы об этом писали. По поводу выложенного проекта, пока смотрим, к обсуждению еще не готовы. Уже писала ,что много работы (помимо схемы МП).
Хорошо :) я тоже пока приостановил деятельность в этом направлении, по таким же причинам ;)
Изменено: Артем Попов - 20.08.2013 18:14:54
Страницы: 1
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)