Update: Wes writes in the comments:
Microsoft has foreseen versioning issues with XAML. The XAML parser does allow custom mappings between names of elements and attributes to their corresponding .NET types and properties, so that is not really an issue.This would seem to allow a developer to map a version 1.0 document's class names and properties to a version 2.0 implementation's classes and properties. Good news. The original concern is still there: that XAML embeds the implementation at all is a stronger bind to dotnet than XML generally should have. But that's a business decision, not a technical one. At least within versioning dotnet applications, using XAML as a "document" should have an upgrade path for document versions.
Original post:
I am not sure about the wisdom of using XAML as a "document" format. As I wondered previously, wouldn't this embed in a "document" essentially the classes, instances, methods, and properties of the *implementation*?
Can someone explain how this isn't so? Or explain why this is a good thing for a document format?
Surely implementations should be able to change without having to upgrade their documents!
3 comments:
XAML contains a reference via the directive to the assembly containing the controls that the document refers to, so the code need not be in the document.
That said, it is conceivable that Longhorn will allow the document to contain code; however, any code would be running in a sandbox, and any attempt to perform an unpermitted operation would result in a Code Access Security exception. Longhorn security does take into account the source of the document, so I am guessing it may be possible for the document to run unrestricted code. (Wesner Moise)
My concern is not about code and security. Rather it is about design and change. If you embed class names and properties, those objects become resistent to change, even if you'd like them to.
Microsoft has foreseen versioning issues with XAML. The XAML parser does allow custom mappings between names of elements and attributes to their corresponding .NET types and properties, so that is not really an issue.
Post a Comment