With all due respect to George and Ira Gershwin, I have a quick question for the readers of this blog. In V1, we have an interesting scenario is talked about frequently, and that's the file extension of our xml form of workflow.
When we debuted at PDC05, there existed an XML representation of the workflow which conformed to a schema that the WF team had built, and it was called XOML. Realizing that WPF was doing the same thing to serialize objects nicely to XML, we moved to that (XAML), but the file extensions had been cast in stone due to VS project setups. So, we had XAML contained in a XOML file.
Is this a problem for you? I could see three possible solutions in the future <insert usual disclaimer, just gathering feedback>:
Is this an issue? Is this something you would like to see changed? Do any of these solutions sound like a good idea, bad idea, etc?
Thanks, we appreciate your feedback :-)
My thoughts on this:
XAML (not the WPF one) is the set of conventions for an XML representation of an object graph. It solves several problems in notations of sub-objects and new stuff like attached properties.
XOML (O for Orchestration) is the XAML-based grammar that assumes a certain dictionary of elements and attributes, corresponding to the WF namespaces and their types.
XAML (from WPF) should be renamed to something like XUML (U for User interface). A different grammar, like XOML, which is also based on the XAML syntax.
|--XEML (E for entities (what the Entity Framework should have used))
There you go: change WPF's extensions, not those of WF.
My preference would be to stick with a single .xaml extension for all variants and rely on the namespaces defined within the file to dictate the variant. I could see the extensions running wild as developers/companies decided they wanted to create their own XAML variant. Of course a drawback is that it would be necessary to open the file to determine the variant.
I would give my vote for .xaml. For me just like html has .html, xml has .xml, similarly xaml should be .xaml (xoml just doesnt make sense to me) as at its core xaml is similar to markup languages (has tags, values etc.) though very powerful, versatile and unique (thanks to WPF, WF) but still you should not forget its deep roots.
If you'll change the extension to XAML then it can cause a problem with the explorer file association - the explorer will not know how to open the file if you'll double click it.
I know that you can write a start selector (like the VS does for .sln files) - but who is going to do that?
I'd say - who cares what is the file extension - it's still (in many cases) compiled into the assembly.
IMO, if we don't get out of the 3/4 char file extention soon, we'll be neck deep in confusion.
Some have suggested that we keep the same extention and have the IDE parse them to determine the 'type' of file it is. If you carried that thought about the future, I would hate to think what that would do to our operating systems and webservers. Sure it will work in our IDE although it would slow it down, but we need to think beyond the IDE and realize that other systems nwill eed to look at the file extention and make a decision quickly.
IMHO, it would not be useful to use multiple extensions for files using the same specification. On the other hand using one extension would cause numerous association issues.
Suggestion would be to use alternate datastreams to store this type of information.
XOML is already a mainstay. Let's call the whole file name change off.
One extension is fine, the namespaces tell us what is contained within.