Proposal: Consider separating XAML from XAML for UI Markup

[lokitoth]

One of the most powerful features of XAML (especially in WPF) is its ability to describe general object graphs - not just those that compose into a UI view.

However, in .NET Core-based platforms there does not seem to be a cross-platform XAML runtime that is separated from the presentation layer in Xamarin and UWP. Having the standardization effort revolving around UI-platforms, I worry that this will further cement XAML = UI, and make it more difficult to drive a generic XAML-based runtime for .NET Core.

A great way to ensure that for non-UI platforms to be able to take advantage of Standard XAML, consider having a layered model of XAML: XAML Core, XAML 2D, XAML UI, etc.

[birbilis]

And why not XAML 3D higher layer too etc. Indeed use layers

[mdtauk]

I agree with the announcement of Fluid Design, XAML needs to have a concept of layers and masking, so things like Paralax will become automatic, as will shadows and positioning in motion.

But the idea of separating XAML from the concept of describing UI... Is that not just XML?

[lokitoth]

@mdtauk: Not quite; I did mean layers in the sense of software dependency layers (and layers of abstraction), rather than visual layers.

And while XAML builds on XML, the additional rules of how XAML binds to (.NET) types and objects to instantiate an object tree is very useful as a data container in general, not just for UI. E.g. I use XAML files for configuration where toolability is critical. Similarly, Workflow Foundation uses XAML for workflow definitions, and with a bit of work this enables visual experiences for people building them by building on top of the XAML designer in Visual Studio.

And why not XAML 3D higher layer too etc. Indeed use layers

@birbilis No reason why it couldn't be done, just from what I recall, it wasn't used in WPF that much, and retain-mode APIs are not generally favoured by developers. Cannot see that I would really want to have to describe a 3D geometry in Path-like syntax.

[birbilis]

People have been using scene graphs and markup for years, see VRML and X3D for example. No need to use Path, want to be able to define own objects apart from pre existing Sphere etc primitives and maybe have grouping objects too and Constructive Solid Geometry primitives like add/subtract etc

[birbilis]

Btw, XAML is supposed to be used in Mixed Reality apps too, why stick to 2D UIs?

[birbilis]

Being able to wire stuff in a 3D scenegraph with each other and with external logic, do animation via timelines, allow to define 3D Ui components etc could be possible

[birbilis]

Eventually could define XAML Profiles, where the MixedReality one would require both Xaml2D and Xaml3D and maybe some more layers or extensions to the core XAML vocabulary.

[lokitoth]

@birbilis Fair points.

[RichiCoder1]

https://github.com/dotnet/corefx/issues/5766 has numerous examples, reasons, and use cases for Xaml to be broken out into the data container format & the visual elements.

[Mike-E-angelo]

Why oh why does MSFT continue to insist that "Xaml is just UI"?! 😉 😉 😉

There are two concerns here: object description (serialization), and UI pretty magic. Echoing @RichiCoder1, a good history of Xaml and uses outside of UI are given in https://github.com/dotnet/corefx/issues/5766. But to (attempt to) give the TLDR version here: System.Xaml started out in PresentationFramework, then was split out into its own assembly, where it was used by Windows Workflow, WPF, and more. Then UWP got the fancy idea of saying that less people using and adopting an assembly is the right way to go, and well, you know the rest and it's basically why we are all here. 😄

[Kation]

We want a base XAML component. Same System.Xaml classes in Full .Net Framework. There can be split many projects like

• System.Xaml This project support to read/write XAML file to/from object.
• System.Xaml.Dependency This project support dependency systems. Include ResourceDictionary, Style, Setter, BindingBase etc.
• Microsoft.Presentation.Core This project support Visual defined classes. Include Visual, UIElement, Media etc.
• Microsoft.Presentation This project support like WPF framework. Include FrameworkElement, FrameworkTemplate, Control etc.

The most important is to public more classes and functions than WPF used.

[jassmith]

Thank you for your interest in XAML Standard. Unfortunately this particular issue falls outside the scope of the XAML Standard specification. We appreciate the community engagement and your input, and do not wish to discourage you from contributing further. We are closing this issue simply because it is out of scope.

If there is something specific in this thread that you think is relevant to the spec, please feel free to open a new issue for discussion.

With love, The XAML Standard Team

[lokitoth]

@jassmith: Sorry to reply to a closed issue, but could you expand a little on how this is outside the scope? I'm not suggesting that actually supporting a non-UI version of XAML be brought to .NET Core - that's a separate issue. Just that the XAML Standard be defined such that a non-UI implementation can still adhere to the non-UI parts, similar to how CSS Modules work (and how different capabilities of HTML5 are independently specced).

The reason I ask is that per my understanding this should be well within scope, so possibly clarifying the actual scope (as opposed to how I perceived it) would help here.

[Mike-E-angelo]

Agreed. Maybe open a new issue @lokitoth and ask for exactly the same thing with a request for guidance on how to adhere to the specification (as opposed to the spec 😉)?

I just checked around in the repo and did not see any such thing. Although the current draft is quite concerning as it is exclusively UI elements.

I'm sort of getting the sense that there might be 2 standards in the making. ;) The one that this repo claims to be making and then the one the community actually wants and will ultimately make.

[jassmith]

The XAML Standard spec as it exists TODAY does not define an object model, it is itself a vernacular of XAML xml. This may change in the future. The frameworks in which you use XAML Standard compliant xml will have their own mechanism of treating XAML. Thus the question of how those parsers actually handle non-XAML Standard XAML (confusing I know) is not relevant to the XAML Standard spec.

[jassmith]

Also @lokitoth don't feel bad about responding to closed issues for now. We are still teasing out the process and there will be hiccups as both the XAML Standard team and the community come to a co-understanding of how this all works.

[dotMorten]

The fact that you say it's confusing, is actually why this is important. Going to Xamarin.Forms from WPF or UWP is confusing because of the extremely different object models. Based on the struggles I've seen people have with Forms,. I think what a lot of users want the most, is to remove the confusion when transitioning from one platform to the other. This includes, perhaps not the full object model, but at least key XAML concepts to also be quite similar in code-behind.

[jassmith]

That would be a new proposal an outside the scope of this one as currently defined. If you do intend to propose it I suggest you flush it out a bit more first just to make sure there is some meat on the bones.

[lokitoth]

@jassmith I was actually going to put together one in my forked repo, but still stuck on cataloguing the existing vocabulary between WPF, SL (all versions), UWP and Forms, to see if I can start naturally teasing out "modules".

Thanks for explaining a bit, though I agree with @dotMorten that you guys are underestimating how much this confusion is making it difficult to easily go back and forth between platforms. To the point that now that you pointed this out, I'd argue that the scope as it stands is a bit too narrow for a repo called "XAML Standard", especially given that focus is on only two of the four major XAML platforms, and solely on capabilities that are used in UI authoring; I'd also argue it is explicitly excluding one of the more popular ones in WPF. In this case, consider specifying that this is work specifically for UWP and Xamarin.Forms v.Next and you'll leave true "deep" standardization ( and reconciliation with the MS-XAML Language Specification ) for later, or never. But communicating that last bit is critical, because otherwise we're stuck guessing about our technology stack decisions.

[dotMorten]

@jassmith I believe that what issue 58 is already trying to do.

[harinikmsft]

@lokitoth and @Mike-EEE - some new principles have been added that should shed some light on what the XAML Standard effort, as defined today, is tracking. A .NET core version of full System.XAML is certainly beyond the scope of XAML Standard v1. That said, like @jassmith says - keep the conversation going, so we can see more concretely what the community is looking for.

[jassmith]

@dotMorten indeed it is, my bad :)

[Mike-E-angelo]

I believe that what issue 58 is already trying to do.

For those of us who are lazy and who feel insulted that someone would make us type something in the URL bar, that's #58. 😉

I'd also argue it is explicitly excluding one of the more popular ones in WPF. In this case, consider specifying that this is work specifically for UWP and Xamarin.Forms v.Next and you'll leave true "deep" standardization ( and reconciliation with the MS-XAML Language Specification ) for later, or never.

<3 Right. The original specification with an incredible amount of effort and detail. Why is that one seemingly being kicked to the side?

I am all for simplifying process, but let's also see if we can make the effort to include some key/core/kernel concepts that made WPF so amazing. It is what developers are looking for when they see "Xaml" after all. Numerous issues in this repo are clearly saying the value found in WPF should be considered and embraced in this new standard.

For instance, maybe ensuring XamlServices and removing coupling to BindableObject which were mentioned to the XF team over two years ago (pssst... that's a long time!): https://bugzilla.xamarin.com/show_bug.cgi?id=26740

In any case, @harinikmsft & @jassmith thank you for continuing the conversation in a closed thread. 😄 I feel it would be valuable to work with @lokitoth to perhaps open a new issue that adheres to the principles you have provided, and maybe even introduce some new ones to improve the process even further. 😉

[Mike-E-angelo]

I have created a new issue that I feel better describes this issue here: https://github.com/Microsoft/xaml-standard/issues/145

@jassmith and @harinikmsft it would be great to get your feedback and input there as well. 👍

[Mike-E-angelo]

A nice FYI/FWIW it's worth here that I have been wanting to share, not just for administrators for this repo but really anyone in the community that will have the dubious task of letting down highly charged (maybe TOO charged, LOL), impassioned, and engaged community members down. If you want a fantastic example of how to close an issue, look no further than this gem by @SteveSandersonMS:

https://github.com/aspnet/JavaScriptServices/issues/963#issuecomment-303156668

This should be engraved in a textbook somewhere, IMO. I happened to be tagged in that thread and was impressed with how it was handled and have been meaning to share here.