Насколько я понял из текста новости, USPTO только-только передали данные, и их ещё не проиндексировали. По крайней мере, один из нужных мне патентов не находится поиском.
1) Нет, в данном случае зависимость описывается на уровне модели. То есть где-то описывается модель класса «Сотрудник», у которого есть атрибуты «Страна», «Офис». Но атрибуты и их свойства задаются, например, через Web-интерфейс (или GUI) системным инженером, не имеющим отношения к программированию. И связь эта обычно задаётся с помощью SQL.
Бизнес-кода в XSLT нет, поэтому никакой дополнительной обработки в XSLT, кроме преобразования в HTML/PDF/PNG/SVG не происходит.
Вся бизнес-логика реализована на Java. И это жёстко — XSLT-преобразование просто не может ничего сделать в системе, для этого нет ни API, ни функций расширения.
P.S.: Пользуйтесь Google, он красивее картинки ищет :)
1) Язык шаблонизатора (XSLT) является основным языком CMS Arp.Site. С точки зрения верстальщика он является конечным языком и не сводится ни к SQL, ни к исходному коду — стандарт XSLT реализован полностью и не расширен с помощью функций. То есть изучить надо только XSLT (ну и HTML), а XPath является его частью.
2) Если же мы говорим о системе управления предприятием, то инженер-настройщик часто в начале не знает ни Java, ни SQL, ни структуры таблиц. Он знает только бизнес-модель, и описать её в терминах XPath'а ему чаще проще, чем в SQL.
1) Иметь серьёзную базу данных с гарантией атомарности хорошо, но для enterprise нужен кластер. Что в этом случае с производительностью — не ясно.
2) Само понятие транзакции означает, что по её завершении обязана быть произведена запись на жёсткий диск либо результатов, либо transaction log. Если этого не делать (или делать не каждую транзакцию), то скорость разумеется возрастает, но надёжность сильно падает — БД уже нельзя назвать транзакционной.
JIT сильно замедляет запуск если нужно ещё сам JVM запускать, которая содержит обычно в 2 раза больше кода, чем само приложение. Если же на всю систему один общий JVM, то JIT может привести и к ускорению запуска приложений.
Более того, если приложения по объёму кода небольшие (100-500 Кб), но долго загружаются (3-4 секунды), то JIT может успеть их скомпилировать ещё в процессе запуска, что ускорит загрузку.
Я попытался использовать hReview для того, чтобы показать количество отзывов (как в примере топика), но ничего не вышло — гугл показывал автора последнего review и дату, а не общее количество. Как сделать так, чтобы оно работало — примеров у Гугла не нашёл.
Как мне найти патент по фамилии автора, если я не знаю номера?
Если серьёзно, то как выкладывал полноразмерные во фликр, так и буду. А контакт обойдётся превьюшками на 640/1280 и ссылкой на оригинал
2) Ок, в отдельном топике.
Вся бизнес-логика реализована на Java. И это жёстко — XSLT-преобразование просто не может ничего сделать в системе, для этого нет ни API, ни функций расширения.
P.S.: Пользуйтесь Google, он красивее картинки ищет :)
2) Если же мы говорим о системе управления предприятием, то инженер-настройщик часто в начале не знает ни Java, ни SQL, ни структуры таблиц. Он знает только бизнес-модель, и описать её в терминах XPath'а ему чаще проще, чем в SQL.
а) у нас есть URI
б) этот URI является XML
Тут же рассматривается другой случай, когда нам нужно получить, грубо говоря, набор URI из чего-то, что напоминает DOM-дерево (информационная система)
Хотя в основе — www.w3.org/TR/xptr-xpointer/ — тот же XPath.
2) Само понятие транзакции означает, что по её завершении обязана быть произведена запись на жёсткий диск либо результатов, либо transaction log. Если этого не делать (или делать не каждую транзакцию), то скорость разумеется возрастает, но надёжность сильно падает — БД уже нельзя назвать транзакционной.
Более того, если приложения по объёму кода небольшие (100-500 Кб), но долго загружаются (3-4 секунды), то JIT может успеть их скомпилировать ещё в процессе запуска, что ускорит загрузку.
Приходится всё делать методом тыка. Неудобно.