Skip to content
This repository was archived by the owner on Mar 8, 2024. It is now read-only.

Conversation

@mossyblog
Copy link

  • The why is important.

  • What isn't tightly coupled to UWP/Xamarin they are coupled to it. To ensure there is a clearly defined line of separation here or its moot to have a standard.

  • Mixing the pitch that UWP/Xamarin are part of XAML is muddying the waters as you also have a legion of WPF/Silverlight minds looking at this to be a way out of the legacy. Until UWP/Xamarin agree on a "merger" the entire repo should defocus on what they do right/wrong today but focus more on what they should be doing tomorrow. This will enable also potential around moving existing legacy Silverlight/WPF into a more modern world without the glitches of UWP/Xamarin implementations.

  • WPF/Silverlight solutions still exist today. Microsoft may not want that reality to exist but in the spirit of OSS its not about Microsoft wants, its about "our" wants.

- The why is important.

- What isn't tightly coupled to UWP/Xamarin they are coupled to it. To ensure there is a clearly defined line of separation here or its moot to have a standard.

- Mixing the pitch that UWP/Xamarin are part of XAML is muddying the waters as you also have a legion of WPF/Silverlight minds looking at this to be a way out of the legacy. Until UWP/Xamarin agree on a "merger" the entire repo should defocus on what they do right/wrong today but focus more on what they *should* be doing tomorrow. This will enable also potential around moving existing legacy Silverlight/WPF into a more modern world without the glitches  of UWP/Xamarin implementations.

- WPF/Silverlight solutions still exist today. Microsoft may not want that reality to exist but in the spirit of OSS its not about Microsoft wants, its about "our" wants.
@dotMorten
Copy link

dotMorten commented May 19, 2017

Although I understand the focus on UWP and Xamarin.Forms I like this change to make it a little less specific. WPF might not be a big part of this standard (if any) but there are also other frameworks that is based on xaml which might want to adopt this standard. It is an open standard. Specifically saying "UWP and Xamarin.Forms" doesn't really make it sound like it's an open standard for others to adopt.

@mossyblog
Copy link
Author

Agreed .. in my mind "could I make java implement xaml" tests like these should be applied in the decision process ..

@riverar
Copy link

riverar commented May 19, 2017

Seems like a good start, but is sorely missing a How do I contribute? section.

There's a tiny text file in the repository with no clear direction. Right now, it looks like we're just re-documenting existing XAML? Is this a legitimate Microsoft project?

Maybe we should bootstrap using a diff of XAML across toolsets and platforms and resolve the conflicts/eliminate ambiguity? Just thinking out loud.

@mossyblog
Copy link
Author

@riverar i wish i could use the eggplant emotive icon on that response.

@Mike-E-angelo
Copy link

Mike-E-angelo commented May 19, 2017

@mossyblog You're always free to describe one in Xaml here. No one will judge you. Much.

@riverar
Copy link

riverar commented May 19, 2017

Looks like @harinikmsft uploaded then deleted a XAML differencing tool. Here's how to be a hacker ☠️ and get the bits.

git clone https://github.com/Microsoft/xaml-standard.git
cd xaml-standard
git fetch origin pull/1/head:xamlstandard_tools
git checkout xamlstandard_tools

@jassmith
Copy link

From the Xamarin.Forms side of things I have no objections to these changes. I will however defer to the UWP team as the changes surrounding WPF/Silverlight developers needs to be decided upon by them.

@jassmith jassmith requested a review from harinikmsft May 20, 2017 00:07
@microsoft microsoft deleted a comment from msftclas Sep 26, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants