With modern browsers supporting XSLT, developers can now use JavaScript to access the power that XSLT provides. JavaScript can enable a web application to load XML data, process it via XSLT into a presentable form and then add it into an existing document. Since the XML data loaded only contains the raw information without any presentation data, it can load quickly even on dialup.

XSLT allows the author to directly manipulate the structure of a document. For example, it permits the rearranging and sorting of elements; it also provides more fine-grained control of the resulting document’s structure.

As of Mozilla 1.2, Gecko enables JavaScript to create XSLT processors. This article covers XSLT/JavaScript bindings in Gecko. They are not available in Netscape 7.0x.

More…

Mozilla supports XSL Transformations (XSLT) 1.0. It also allows JavaScript to perform XSLT transformations and allows running XPATH on a document.

Mozilla requires that you send the XML and XSLT file holding the stylesheet with an XML mimetype (text/xml or application/xml). This is the most common reason why XSLT won’t run in Mozilla but will in Internet Explorer. Mozilla is strict in that way.

Internet Explorer 5.0 and 5.5 supported XSLT’s working draft, which is substantially different than the final 1.0 recommendation. The easiest way to distinguish what version an XSLT file was written against is to look at the namespace. The namespace for the 1.0 recommendation is http://www.w3.org/1999/XSL/Transform, while the working draft’s namespace is http://www.w3.org/TR/WD-xsl. Internet Explorer 6 supports the working draft for backwards compatibility, but Mozilla does not support the working draft, only the final recommendation.

If XSLT requires you to distinguish the browser, you can query the “xsl:vendor” system property. Mozilla’s XSLT engine will report itself as “Transformiix” and Internet Explorer will return “Microsoft.”

<xsl:if test=\"system-property('xsl:vendor') = 'Transformiix'\">
  <!-- Mozilla specific markup -->
</xsl:if>
<xsl:if test=\"system-property('xsl:vendor') = 'Microsoft'\">
  <!-- Internet Explorer specific markup -->
</xsl:if>

Internet Explorer has a nonstandard feature called XML data islands, which allow you to embed XML inside an HTML document using the nonstandard HTML tag <xml>. Mozilla does not support XML data islands and handles them as unknown HTML tags. You can achieve the same functionality using XHTML; however, because Internet Explorer’s support for XHTML is weak, this is usually not an option.

One cross-browser solution is to use DOM parsers, which parse a string that contains a serialized XML document and generates the document for the parsed XML. Mozilla uses the DOMParser class, which takes the serialized string and creates an XML document out of it. In Internet Explorer, you can achieve the same functionality using ActiveX. A new Microsoft.XMLDOM generates and has a loadXML method that can take in a string and generate a document from it. The following code shows you how:

<xml id=\"xmldataisland\">
  <foo>bar</foo>
</xml>   
	
Cross-browser solution:
 var xmlString = '<xml id=\"xmldataisland\"><foo>bar</foo></xml>';
 var myDocument; 
	
 if (document.implementation.createDocument){
   // Mozilla, create a new DOMParser
   var parser = new DOMParser();
   myDocument = parser.parseFromString(xmlString, 'text/xml');
 } else if (window.ActiveXObject){
   // Internet Explorer, create a new XML document using ActiveX
   // and use loadXML as a DOM parser.
   myDocument = new ActiveXObject('Microsoft.XMLDOM')
   myDocument.async='false';
   myDocument.loadXML(xmlString);
 }

Whilst working on the Ajax Link Tracker and MapSurface I have come across an inconsistency in how the href attribute is retrieved using DOM Scripting.

The href attribute is different to other element attributes in that the value set can be relative to the context of the page URL. If you set a link with a relative href attribute

<a href=”../development/test1.html”>test page</a>

The browser will look at the pages current URL and derive an absolute URL for the link.

http://www.glenn.jones.net/development/test1.html

This is the root of the problem, some browsers return the text of the attribute and others return the derived absolute URL. The results also differ by the method you use to retrieve the href attribute. There are three common ways to access an attribute:

linkobj.href;
linkobj[‘href’];
linkobj.getAttribute(‘href’);

The linkobj.href and linkobj[‘href’]; methods of accessing the attribute consistently return the derived absolute URL.

Microsoft has tried to address this by problem adding a second parameter to the getAttribute method. The second parameter can be set to 0,1 or 2. If the parameter is set to 2 the method returns the attribute text. Any other setting will return the derived absolute URL.

linkobj.getAttribute(‘href’);
linkobj.getAttribute(‘href’,2);

Get attribute test page Test on IE6, Firefox 1.5 and Opera 8.51.

Microsoft официально заявила о переименовании своего API WinFX в более
привычный для слуха .NET Framework 3. Это, вероятно, последнее
переименование. Нет уже Longhorn (Vista), канули в прошлое Avalon (WPF),
Indigo (WCF). Время пришло переименовать WinFX…

Следующие можно прочесть на MSDN блоге Сомасежара, работника Microsoft:

Цитата:
*Когда ты говоришь разработчикам о WinFX единственный возникающий вопрос это
– «WinFX звучит великолепно, но куда подевался .NET?». .NET Framework
становится самой успешной платформой в мире. Разработчики знают и любят
.NET.

.NET Framework всегда был в ядре WinFX, но название WinFX не говорило об
этом. Термин WinFX помог нам ввести такие инновационные бренды, как Windows
Presentation Foundation (WPF), Windows Communication Foundation (WCF),
Windows Workflow Foundation (WWF) и недавно переименованный Windows
CardSpace (WCS), ранее известный под кодовым именем InfoCard. Но этот бренд
также создал неестественную неоднородность между предыдущими версиями наших
платформ и новыми.

Именно поэтому было принято решение о переименовании WinFX в .NET Framework
3.0. .NET Framework 3.0 точно описывает нашу платформу – следующую версию
нашей платформы для разработчиков.

Изменение произошло только в имени и никак не отразится на технологии. .NET
Framework 3.0 продолжает состоять из таких компонентов как .NET Framework
2.0, ASP.NET, WinForms, ADO.NET, дополнительных библиотек и CLR, также как и
абсолютно инновационных технологий WPF, WCF, WWF и WCS.

.NET Framework 3.0 также будет поставляться вместе с Windows Vista и будет
доступен для Windows XP и Windows Server 2003. Это изменение никак не
отразится на планах относительно Windows Vista или самого .NET Framework 3.0
.

Мы уверены, что это изменение откроет глаза многих людям, заблуждающимся и
непонимающим значения наших платформ.*

Как видно из этого текста, не только с WinFX прощаемся мы, но и с InfoCard.
Нечто подобное мы можем прочесть и на блоге Дэга Махуга:

Цитата:
*
WinFX становится .NET 3.0
Для упрощения стратегии инструментов разработки Microsoft и чтобы сделать
разработчикам более ясным этот сегмент, сегодня днем произошло новое
изменение: WinFX теперь известен под именем третьей 3.0 версии .NET
Framework. Это не отразится на самой технологии: все относящееся к WinFX
осталось по-прежнему, включая технологии WPF, WCF, Workflow и новые API,
которые будут частью .NET 3.0.*

Источник: http://blogs.msdn.com/dmahugh/ http://blogs.msdn.com/somasegar/
*Перевод: Райкер*

Корпорация Microsoft в рамках ежемесячного обновления своих программных
продуктов выпустила очередную порцию заплаток для операционных систем
Windows.

Одна из критически опасных уязвимостей
найдена http://www.microsoft.com/technet/security/Bulletin/MS06-026.mspx в
механизме обработки изображений Graphics Rendering Engine. Для
реализации
атаки злоумышленнику необходимо вынудить жертву открыть специальный
графический файл в формате WMF. Эксплуатируя дыру, нападающий может
выполнить на ПК произвольный код. Брешь присутствует только в Windows 98/98
SE/ME.

Особенности обработки изображений в формате ART позволяют получить
несанкционированный доступ к компьютерам под управлением Windows ХР/Server
2003. Для этого также необходимо вынудить жертву особый графический файл.
Брешь, подробнее о которой можно узнать
здесь http://www.microsoft.com/technet/security/Bulletin/MS06-022.mspx,
названа критически опасной.

Для пользователей приложения Windows Media Player версий 9 и 10 опасность
могут представлять графические изображения в формате PNG. Реализовать атаку
можно через веб-сайт или WMZ-файл, при открытии которого происходит
переполнение буфера. Дыре
присвоен http://www.microsoft.com/technet/security/Bulletin/MS06-024.mspx рейтинг
максимальной опасности.

Еще две критически опасные уязвимости выявлены в компонентах RRAS (Routing
and Remote Access Service) и JScript. В первом случае атакующий может
спровоцировать http://www.microsoft.com/technet/security/Bulletin/MS06-025.mspx ошибку
переполнения буфера на компьютере-жертве и выполнить произвольный
код. Дыра в модуле JScript
позволяет http://www.microsoft.com/technet/security/Bulletin/MS06-023.mspx повредить
данные в памяти и перехватить контроль над машиной.

Две уязвимости в Windows охарактеризованы корпорацией Microsoft как важные.
Одна из них связана http://www.microsoft.com/technet/security/Bulletin/MS06-032.mspx с
реализацией протокола TCP/IP в ОС Windows 2000/ХР/Server 2003 и
позволяет
злоумышленнику получить доступ к данным. Организовать атаку можно только в
том случае, если на удалённой машине активирована служба IP Source Routing
или RRAS. Вторая дыра обеспечивает возможность повышения привилегий
пользователя. Уязвимость http://www.microsoft.com/technet/security/Bulletin/MS06-030.mspx может
быть задействована через специальный SMB-запрос (Server Message
Block).

Наконец, ещё одна дыра связана с особенностями реализации функции взаимной
аутентификации в службе удаленного вызова процедур (RPC). Уязвимость не
представляет особой опасности и присутствует только в операционной системе
Windows 2000. Подробнее о проблеме можно узнать
здесь http://www.microsoft.com/technet/security/Bulletin/MS06-031.mspx.

http://security.compulenta.ru/273163/

Сразу несколько компаний, специализирующихся на вопросах компьютерной
безопасности, сообщили об обнаружении уязвимости во всех распространенных
браузерах.

Дыра, о которой идет речь, как
отмечает http://www.techweb.com/showArticle.jhtml?articleID=188702202 Techweb,
теоретически позволяет злоумышленникам получить несанкционированный
доступ к конфиденциальным пользовательским данным, например, информации о
банковских аккаунтах или паролям. Проблема связана с функцией JavaScript
“OnKeyDown” и обеспечивает возможность перехвата строк, введённых
пользователем с клавиатуры в форму на веб-странице.

По информации датской компании Secunia, брешь присутствует в браузерах
Internet Explorer версии 6.х и более ранних модификациях, Firefox версий 1.х,
Netscape 8.х и более ранних модификациях, Mozilla версий до 1.7.х и пакете
SeaMonkey 1.х и ниже. Ситуация ухудшается ещё и тем, что проблема не зависит
от используемой на компьютере операционной системы - нападение может быть
осуществлено на машины, работающие под управлением Windows, Linux и Mac OS
X.

Патча для дыры в настоящее время не существует. Впрочем, нужно отметить, что
организовать атаку на компьютер через данную брешь можно только при условии
выполнения определённых действий потенциальной жертвой. Поэтому компания
Secunia охарактеризовала брешь малоопасной. С примером программного кода,
позволяющего задействовать уязвимость, можно ознакомиться
здесь http://lists.grok.org.uk/pipermail/full-disclosure/2006-June/046610.html

http://tec.net.ua/books

http://www.i-see.net/bindows/bindows/samples/applauncher/

http://www.walterzorn.com/dragdrop/dragdrop_e.htm