Introduce (Separate) Microsoft.Xaml and Microsoft.Xaml.UI Specifications

[Mike-E-angelo]

In reading and participating in the incredible discourse and dialogue found within this repository, I and others have encountered two distinct areas that developers believe a standard is being written around:

• Application objects (POCO) serialization mechanics and syntax
• User interface elements and user experience process and workflow

It is clear that since WPF/Silverlight, MSFT has intended "Xaml" to mean the latter, while developers who have been steeped within the wondrous powers of System.Xaml are concerned and wish a return for the former.

To account for this, I would like to suggest the following:

The Microsoft Xaml Standard: The top, encompassing umbrella of ALL THE XAML!

This standard consists of two distinct specifications:

• Microsoft.Xaml: The root specification for all aspects for serialization of application objects (POCO) and components necessary to do so. This includes marked and known concepts such as markup extensions, attached properties, content properties, and metadata-based components such as XmlnsDefinitionAttribute and more (will update this list as conversation matures).
• Microsoft.Xaml.UI: The official specification for all known UI and UX components in the Xaml ecosystem. This is pretty much what XF/UWP teams are angling for and what they feel this repo is about. This includes everything UI/UX-related such as common controls, and the "fixed" naming between those controls.

It is worth noting that there are already several serializers that exist in the Xaml space to serialize application objects (POCOs) for use in a cross-platform manner. These includes the great work of @SuperJMN's with OmniXaml and @cwensley with Portable.Xaml. Additionally (and I really hesitate to mention this as it is a whiles away before it is "done" and ready for showtime), but the work that we are doing in the ExtendedXmlSerializer v2 also has an Xaml component as well.

The idea here is that these serializers (and possibly more in the future) can be brought to bear under this serialization standard, and that developers can "BYOXSS" (Bring Your Own Xaml-Standard Serializer) and easily plug them into the applications that they are building. Doing so will mean that these serializers meet the minimum expectations to successfully load and save application objects (either POCO or UI) in a standards-compliant manner, while being confident knowing that their object graphs are serialized and deserialized in a way that can be shared amongst other applications that have incorporated their own Xaml-Standard-compliant serializers as well.

[birbilis]

Indeed need a Xaml core/basis which sorts out things like using: vs xmlns: etc.

Also wouldn't mind to see Xaml.UI.2D and Xaml.UI.3D extensions above a basis Xaml.UI one

[SuperJMN]

Thanks for the mention of my work, OmniXAML. I'm still working hard and the current design is so powerful that I encourage the team to take a look at the most recent [branch](https://github.com/SuperJMN/OmniXAML/tree/mas_dificil_todavia), specially the Tests (here and here).

It supports a totally extensible dependency injection mechanism that makes it able to instantiate immutable types, using IoC containers or whatever you may want.

You can use it as a starting point, although it already parses a wide range of XAML constructs.

BTW, I support you BYOXSS approach. One thing should be the XAML parser (deserializer) and another, the object model. People usually don't know that XAML doesn't have nothing to do with StackPanels and TextBlocks.

[Mike-E-angelo]

Also wouldn't mind to see Xaml.UI.2D and Xaml.UI.3D extensions above a basis Xaml.UI one

Indeed, @birbilis ... XF was/is very 2D/LOB centric, but at some point 3D will be a focus as well, espcially with the holoness around the corner.

People usually don't know that XAML doesn't have nothing to do with StackPanels and TextBlocks

❤️ Very happy to have you on board, @SuperJMN! Also, don't ask me how to pronounce BYOXSS. 😆

[Mike-E-angelo]

Related issues:

https://github.com/Microsoft/xaml-standard/issues/27 https://github.com/Microsoft/xaml-standard/issues/119 https://github.com/Microsoft/xaml-standard/issues/141

[mdtauk]

Xaml.Fluent Xaml.Material Xaml.iOS Xaml.WPF Xaml.Legacy (Silverlight WP7/8) Xaml.Tizen - Xaml.Unity etc

So anyone who wants to extend Xaml.UI can do so to make a particular flavour of XAML. And the "purity" of XAML can be managed by committee, and it allows it to become popular

[insinfo]

I understand that have discussed things like: Default user controls vs. various features bound to these controls, plus in the end XAML is basically a markup language for heaping controls and defining their properties and bindings to create a graphical interface. I think not the separation between one thing and another.

I think if you keep doing so much Segmentation like this: There will not be a Standard.

I think the idea here is Unification, and leveling all platforms, so that it is written once and compile to any place, without changes, be it desktop (Windows, MacOS, Linux), mobile (Android, IOS, Windows mobile) , Embedded (Iot, AR/VR and etc. To be able to share code between several platforms, which implements XAML Standard For this I think that instead of segmenting we have to create a robust and well complete unified core that covers features of the main platforms (Microsoft, Google and Apple) This will attract developers from all platforms, and will not hinder the transition because most of the features he already used are already here too

[mdtauk]

@insinfo I don't think the goal of XAML Standard, is to unify what XAML does for all platform UIs, nor is it creating a UI system to supplant/replace the native UI of platforms.

I think (and I may understand this wrong) it is about defining how XAML is formed, establishing the basic conventions for the markup language, and then building in extensability so those who decide to add XAML support to their platforms/frameworks/rendering engines, can say "we support XAML Standard 1.0" etc.

So when adding a button to a XAML document, you are not adding in a UWP control, you are adding an instruction to the platform, to place a button into this page. And it is still a native button from UI Kit or from Android API Libraries etc.

If this is the case, then having a pure definition of XAML as a markup language, with a clear way to extend it as needed. Then it allows XAML to be used however the vendor needs it to be, and if Microsoft wants to create variations to work with Fluent Design, then it can, as can Samsung make one for Tizen UI, etc.

So when making a cross platform UI, you share the XAML bits that are standard, and then include support for the platform specific features/controls/concepts by declaring that you support XAML, XAML.UI, and XAML.UWP etc

[birbilis]

Btw, not with some Microsoft. prefix if it is to be a standard

[dotMorten]

@mdtauk that suggestion sounds an awful lot like PCL which was quite a mistake and why we now have .NET Standard

[mdtauk]

@dotMorten Then what is XAML Standard for? It doesn't aim to be a cross platform renderer does it? It is only trying to include those controls which are common across various existing platforms and UI Kits right?

If it only aims to be a 1 to 1 match for other UI sets, then it won't offer the best of UWP and WPF implementations, and it won't allow the inclusion of controls specific to other platforms.

What are the long term goals for the standard, if not to be extendable?

[swythan]

This is exactly what I was thinking when I was reading through all the "strongly held opinions" in #97. :-)

(Quick aside: I do like the fact that this effort is happening. I very much want it to succeed.)

I was previously under the impression that we had a standard for XAML. I thought there were two, in fact, the one that WPF uses (XAML2006?), and the one that was implemented, but WPF never bothered to support (XAML2009?). Other than WPF, I've done a bit of Silverlight for WP, but that was pretty similar. I was clear that UWP and X.F had their own UI frameworks and a couple of missing/extra pieces, so I knew you couldn't share the XAML (like between WPF & SL), but I think what I'm hearing is that they don't even follow the same basic standard for XAML itself. If so then that's a pretty horrific place to be, and I can only wonder as to why.

So: That's got to be the first thing to sort out: a XAML2018 specification for the XML syntax that everyone can agree on. Without that we're dead in the water, right?

What would then be nice is to have a guaranteed subset of functionality that is shared between UI toolkits, such that real-life UI definitions can be used across platforms. Since XAML is basically an object serialisation framework that sounds to me like a description of a set of classes and their functionality (just like .Net Standard), along with which XML namespaces they'd be mapped to.

Having thought about what "XAML" actually is, I would expect the former to be "XAML Standard" and the latter to be something else (it can be in the same repo and marketing literature if you want). The two efforts can largely exist in parallel, I would imagine, except when it comes to functionality that gets surfaced directly in the XML (e.g. markup extensions, x:Bind, etc).

Anyway, I think a clear delineation between the two parts of the project (parser & toolkit) would help avoid misunderstandings.

PS: I also agree with Scott Barnes' blog post. I would love to to hear about the "Why", and it seems like reaching out to designers and 3rd party tooling vendors will be critical to getting this right.

[Mike-E-angelo]

If so then that's a pretty horrific place to be, and I can only wonder as to why.

😆

But really, great thoughts, @swythan. To add to the chaos here. WPF actually does support 2009, and so does XF. UWP, however, well. Who knows what that does. 😉 In WPF's case, it's the tooling (Visual Studio) that does not support 2009.

But you are correct, however, both 2006 and 2009 are specifications. I myself might have conflated this with a "standard". However, that doesn't mean that this new specification cannot be a part of this, as you have said.

What's important here is that stating that you have a "Xaml Standard" that is simply adjustments in UI "vernacular" (a good way of putting it, @jassmith) is at best misleading and worst ALLTHECONFUSE!!!

Consider there are now at least five 5 parsers that can (or will 👼) parse legitimate Xaml:

• WPF (truly "ubiquitous" from a desktop market perspective)
• Xamarin.Forms
• OmniXaml
• Portable.Xaml
• ExtendedXmlSerializer

It is inevitable that one of these will introduce some novelty towards introducing new/fancy/evolved concepts in which developers will gravitate towards, and may or may not be adopted by the others. That is exactly the sort of thing that specifications are geared to mitigate.

Finally, I lurve the 2018 date for a "new" specification! Although, seeing on how it took the UWP team nearly seven years to acknowledge the concept of markup extensions, we might want to consider moving it back a decade or two, just in case. Maybe a specialized "UWP Specification" for 2050, and everyone else 2018. 😉

(I kid I kid... don't take me too seriously, y'all.)

[insinfo]

@swythan I fully agree with this statement "and it seems like reaching out to designers and 3rd party tooling vendors will be critical to getting this right."

[markrendle]

Have I missed something?

I thought XAML Standard was just a consistent set of names for UI elements and attributes that would be respected by WPF, UWP and Xamarin.

What's all this talk about XAML as a POCO serialization format and whatnot?

[birbilis]

The community hopes for more to help make XAML that is shared between XAML-based platforms.

So apart from common control definition you need to first define other underlying concepts in

[birbilis]

...a separate profile (a core one)

[Mike-E-angelo]

I thought XAML Standard was just a consistent set of names for UI elements and attributes that would be respected by WPF, UWP and Xamarin.

You did miss something, @markrendle. WPF is not even considered part of the standard at the moment. Your contribution and upvote to the conversation would be greatly appreciated!

As @birbilis noted, this issue tracks a significant conceptual understanding when the word "Xaml" is used -- indeed, that of serialization as you note. This unfortunately has been lost with the UWP Xaml system (& Xamarn Forms to a lesser degree) and one that we hope to regain in future versions of Xaml serializers going forward.

As noted earlier, there are at least three community efforts now that have undertaken and address Xaml serialization in some capacity. If you are aware of any others, please let us know so that we can add them to this issue as well. We are hoping to ensure these are accounted for in any new Xaml Standard that is created.

What that looks like exactly is what this issue aims to define. 😄

[Duranom]

I remember the times when XAML was used for more than just UI for applications, but I also remember when most non-UI version dissappeared in favour of XML itself or even other types because most parties also found it too heavy and overtyped for what it was used and doubt it will come back for such things.

That aside I agree with the separation, though the Microsoft.Xaml will most likely not change or contain and should be abit more clear or at least very restrictive on what is allowed. Like do you want Binding definition in Microsoft.Xaml or in the Microsoft.Xaml.UI as it makes more sense there.

[insinfo]

When proposing the creation of a new open standard of a markup language for the creation of graphical interfaces, it is logical to assume that there will be proposals for new parameters, resources, reserved words, interface controls among other things. And there will be a lot of implementation work by those who want to support compatibility with this new standard. Therefore, it is the place and opportunity for developers to indicate the controls or features they want in the specification and that logically consequently enter into APIs that want compatibility with this new standard. If it's just to combine Xamarin.Forms with UWP, then it's not a new open standard and it does not need the community to do this, or we're wasting our time here then.

[Mike-E-angelo]

If it's just to combine Xamarin.Forms with UWP, then it's not a new open standard and it does not need the community to do this, or we're wasting our time here then.

From MSFT's perspective, I would be kind of miffed that the community hasn't been exactly accepted this with open arms exactly as intended. However, the opportunist in me would also recognize that there is some opportunity here to expose unpaid labor to help with my budget and bottom line. 😆 👼

On my side, I have actually grown more accepting of the intent and original spirit of this repo and would be more understanding if issues that were not 100% aligned with this vision were shut down. That's not to say I would still not be heartbroken, however. 💔 Haha. But at least it does sound like at least someone over there is listening in an engaging, caring way and that is more than we have had for what seems for far too long.

Let's please keep in mind our intentions are to not only further the branding and power of a key (innovative) MSFT technology, but also make our development lives a lot more effective and efficient when we're designing and developing our .NET solutions. Those who have done WPF and Silverlight development understand what this feels like, and that is what we are seeking to regain here -- housed in a modern, performant casing to boot. 👍

[birbilis]

related comment by @SuperJMN here: https://github.com/Microsoft/xaml-standard/issues/20#issuecomment-304260679

[birbilis]

should also add Xaml.Services (I'd skip Microsoft. prefix if XAML is to be a standard) separately https://docs.microsoft.com/en-us/dotnet/framework/xaml-services/index though some of that part would go to the base Xaml spec (or could have Xaml.Extensibility or whatever)

[juepiezhongren]

xaml is to be the uni ui standard to replace html, in my opinion

[CZEMacLeod]

Just to touch on @Mike-EEE 's comment regarding other uses for XAML - We use it to define documents which are bound to a model that then generate XpsDocuments from a FlowDocument - This isn't UI/UX (there are no 'controls') as defined above and indeed is done in a web service to generate various documents from our system. XAML Standard should really cover these scenarios, and not be limited to just UI. Although I also think it important to have a XAML UI standard too.