Friday, July 30, 2004 - Posts
According to Benjamin Mitchell's post from a TechEd Don Box Service Orientation presentation, we don't know when or if SAML will be directly supported:
WS-Security vs. SAML?
There are many different kinds of tokens that may be used, such as Username, X509 certificates and Kerberos tokens. Don said it was unlikely that a token type, like SAML will become the 'single token format to rule them all'. No definite answer on where the SAML support was. As I learnt on Saturday, trying to implement SAML support is a non-trivial exercise - it would be nice if there was a clear statement from Microsoft on when it will be supported in the platform (so that you don't have to share my dll in order for us to use it when we talk). I think it will be part of the identity management work in future.
Michele Leroux Bustamante's very philosophical post on the same talk elucidates the "Saturday" comment: She and Benjamin wrote a sample SAML implementation, So Benjamin ought to know.
Here's his post before the presentation.
Darrel Norton digs up a presentation by Mike Cohn comparing five agile processes:
- FDD
- Scrum
- Extreme Programming
- Crystal
- DSDM
'Course my leanings are otherwise.
Dare shares gudelines on how to design extensible, versionable XML vocabularies.
The outline is:
Message Transfer Negotiation vs. Versioning Message Payloads
Version Numbers vs. Namespace Names
The Difference Between Versioning and Extensibility
Guidelines for Designing Extensible XML Formats
- XML formats should be designed to be extensible.
- Extensions must not use the namespace of the XML format.
- All XML elements in the format should allow any extension attributes, and elements with complex content should allow for extension elements as children.
- Formats that support extensibility must specify a processing model for dealing with extensions.
Why XML Formats Should Be Designed to Be Extensible
Why Extensions Mustn't Use the Namespace of the XML Format
Using XML Schema to Design an Extensible XML Format
Guidelines for Designing Versionable XML Formats
- If the next version of a format is backward compatible with previous versions, then the old namespace name must be used in conjunction with XML's extensibility model.
- A new namespace name must be used when backward compatibility is not permitted. That is, software must break if it does not understand the new language components.
- Formats should specify a mustUnderstand model for dealing with backward incompatible changes to the format that don't change the namespace name.
Using XML Schema to Design a Versionable XML Format
I believe I failed to post about this back when it was announced in May: .NET 2.0 will support XQuery 1.0 but will not support XPath 2.0/XSLT 2.0. [However it will still support XPath/XSLT 1.0] See the posting by Dare Obasanjo's boss Mark Fussel and Dare's post here. (Arpan Desai, the XQuery program manager, has more analysis here.) The posts also imply that they are not inclined to support XSLT 2.0 in the future.
My colleague who sits on a working group for an industry standard XML vocabulary was very chagrined to read about Microsoft's direction and the implications for his standard.
The waters do seem a bit cloudy, however. Arpan Desai seems to suggest in a response to Dare's post, that XPathNavigator and other “XPath” queries will just use the XQuery data model, so there's no need to worry about whether you can use the new syntax in the standard XML classes; you can. However, XSL Transformations proper must be XSLT 1.0 stuff.
All hope is not lost. In a later post by Dare asking for input for the Longhorn Framework XML library folks asked for XSLT 2.0 support. He even muses about it in a later post, but is is presented with a surprise.