単に.uiはどうですか？

この区別は、島以外の場合にも役立つでしょうか、それとももっと混乱するでしょうか？

または、これが主に同じソリューション内のWPFとWinUI Xamlを区別するためのものである場合、 .winui.xamlや.island.xamlのような規則はどうでしょうか。 そうすれば、おそらく既存のツールを使いやすくなるでしょう。

これはXAMLアイランドのシナリオ用ですか、それともどこでも使用できますか？ 他のすべてのシナリオでは、混乱を引き起こし、人々に移行を強制する以外に、これの価値が何であるかわかりません（そして、おそらく古いバージョンのVSのような多くのツールの下位互換性を壊します）。 「whatever.winui.xaml」のような規則はおそらく破壊的ではありませんが、それでも他の場所ではなく、島の範囲でのみ有用であることがわかります。

議論をXAMLアイランドだけに限定したくないので、タイトルを変更します。

.xamlを使い続けると言います。 WinUiのスコープ（および名前）は、ウィンドウの横にある他のプラットフォームを含むように変更される可能性があります（おそらくUnoPlatformを介して？）。 プロジェクトの名前が変更された場合はどうなりますか？

私はNOにもっと傾いています。 マイクロソフトは、製品/サービスまたはそのユーザーに損害を与えるために、製品およびサービスの名前変更を何度も行ってきました（意見）。 これはまた別の名前変更です。

これはXAMLアイランドのシナリオ用ですか、それともどこでも使用できますか？ 他のすべてのシナリオでは、混乱を引き起こし、人々に移行を強制する以外に、これの価値が何であるかわかりません（そして、おそらく古いバージョンのVSのような多くのツールの下位互換性を壊します）。 「whatever.winui.xaml」のような規則はおそらく破壊的ではありませんが、それでも他の場所ではなく、島の範囲でのみ有用であることがわかります。

どこにでも

XAMLは.xamlのままにする必要があると思いますが、従来のXAMLに置き換わるか、従来のXAMLと一緒に役立つ新しいものが表示される場合は、 .winui拡張子が役立つ可能性があります。 ＃804 :)

このリクエストは私を完全に混乱させます...何が起こっているのかを理解するためにこの問題を2回読む必要がありました...これは、さまざまな方言よりもxamlエコシステムを本当に断片化します。

今言葉を失った...

@liquidboyまあ、それはこの変更を行わないことを支持する少なくとも1つの明確なフィードバックです:)あなたの声を貸してくれてありがとう。

@jesbisのアイデアが気に入っています。おそらく、Islandsコンテキストで実行されているXAMLファイルと実行されていないXAMLファイルの違いをより簡単に区別するのに役立つ*.islands.xamlを追加できます。

不思議なことに、島のXAMLファイルにのみ適用される.islands.xamlを使用する方がよいでしょうか、それとも、どこでも全体的な拡張機能として.winui.xamlを使用する方がよいでしょうか。 これらの2つのアイデアのうち、どちらが好きかわかりません。

私の投票は、「。islands.xaml」または同様のものが島で推奨される（ただし厳密には強制されない）パターンであり、他のすべての場所で.xamlファイルはまだ.xamlファイルです。 そうすることで、島を使用しない人々に不必要な影響を与えることを回避できます。

私の最大の懸念は、すべてのツールから来ています。 別の拡張子で問題はありませんが、これは、.xamlファイル拡張子に依存するすべてのツールを更新する必要があることを意味します（R＃、 XamlStylerなどを考えています）。 xamlを取り巻くツールのサポートは、すでに苦労しているように感じられます。これにより、さらに悪化する可能性があります。

私の$ 0.02

おそらく、問題のタイトルを次のように変更する必要があります。
Xaml諸島用のXAMLファイルは、WinUI 3プロジェクトで別のファイル拡張子を持つ必要がありますか？

.xamlをそこに保持することに強く賛成です。 .ui.xamlまたは.xaml.uiを使用する場合もありますが、テクノロジは強力であり、ヘルプを利用できます。 一方、残念ながら、xamlには、wpfパフォーマンスの落とし穴、Silverlight、およびWindows Phoneの後にいくつかの汚名があります。そのため、よりクリーンなファイル名が角を曲がるのに役立つ可能性があります。 私はまだxamlが大好きですが、明確に考えられていない限り、テクノロジー名についてこれ以上混乱する必要はありません。

winuiがクロスプラットフォームになると（多くのWindowsのものがそうであるように）、より適しているので、単純に.uiとして使用することをお勧めします。

これは、将来の保証になることを意味します。

コードファイルの拡張子は.ui.csで、自明で読みやすいものになります。

.winui.xaml

つまり、.winui.xaml.csファイルがあるということですか？ うわぁ..

json形式を使用します。 2020年です。

JSONは過酷で、操作があまり簡単ではありません。

json形式を使用します。 2020年です。

JSON形式は、人間ではなく、コンピューターが読み取るためのものです。 読みづらく、見栄えも良くありません。

.winuiは初心者をあきらめると思います。 新しい言語を学ぶべきだと思うからです。 そして今、WinFormsとWPFとUWPとSLとASPとASP.NETCoreがあります。 私たちはそれを学ぶためにますます多くの時間を費やすべきですが、継承するべきではありません。 常に新しい技術を作るべきではないと思います。

申し訳ありませんが、私と私の友人の多くは新しいことを学ぶのが好きではありません。 マイノリティになることを期待しないのであれば、テクノロジーを継承し、再利用して互換性を持たせることができるようにする必要があります。

私の意見では、「どのXAMLがどれであるか」に対するより洗練された解決策は、このコメントの@grokysによって提案されているように、デフォルトのxmlns名前空間に依存することです： https ：//github.com/AvaloniaUI/AvaloniaVS/issues/95#

UWPではこれを行いませんでしたが、WinUI用に変更できる可能性があります。

私の意見では、このコメントの@grokysが示唆しているように、「どのXAMLがどれであるか」に対するより洗練された解決策は、デフォルトのxmlns名前空間に依存することです。AvaloniaUI / AvaloniaVS＃95（コメント）

UWPではこれを行いませんでしたが、WinUI用に変更できる可能性があります。

HTMLの場合と同様に、Doctypeに相当するものを導入できますか？

HTMLの場合と同様に、Doctypeに相当するものを導入できますか？

おそらく、しかし私たちはそうする必要はありません。 デフォルトの名前空間は、それぞれの異なるプラットフォームを区別するものでなければなりません（結局のところ、それらはコードビハインドで行われます）

xamlを取り巻くツールのサポートは、すでに苦労しているように感じられます。これにより、さらに悪化する可能性があります。

@kebooこれは私にとって本当に大変なことであり、私たちが修正して正しく行うために私が強く求めているものです。
私たちが（島のシナリオでは）それらを区別できない世界にいるという事実は、ツールが何年にもわたってどのように進化してきたかによるものです。 すべてが完全に分離されており、異なる方言間の違いを合理化することはほぼ不可能です。 これを変更して、XAMLの解析とコンパイルを、すべてのXAMLダイアレクト間で簡単に共有できるものにします。この例では、WinUIとWPFが同じ基本エンジンを使用しています。 ツールは、デフォルトの名前空間で宣言されているようにプラグイン可能である必要があり、必要に応じてカスタマイズできます。 私の意見では、このシナリオを適切に機能させるために、それ以上のものは必要ありません。 それは大きな努力ですが、私にとってそれは私たち全員にとって正しいことです。

@stevenbrixプラットフォームは現在、アイランドの状況でXAMLが使用されていることを理解しますが、この問題について私が読んだのは、開発者がWinUI3.0内で.xamlファイルがどのように消費されるかを伝えて理解するための方法です。事業。

一般的なXAMLツールに関しては、設計時のエクスペリエンスIMOを完全にやり直す必要があります。 Expression Blendは、XAMLの設計と開発が一流であると感じた最後の機会でした。

XAMLの性質上、これは書面形式であると同時に視覚形式でもあります。 Visual XAMLデザインは、Intellisenseを高品質にするために後部座席を取りました。 堅牢でパフォーマンスが高く、XAML設計エクスペリエンスのプロトタイプ作成と研磨の両方が簡単にできるとしたら、コミュニティを活性化させることができます。

プラグインアプローチは、制御ベンダーやツールキットベンダーが行うために多くの作業を必要とせず、優れた設計時間、ツールパレット、要素プロパティのエクスペリエンスを提供するのに非常に役立ちます。 XAMLが他の非従来型のフォームファクタに移行するにつれて、設計ワークフローを検討する必要があります。 2つのペインビュー（NeoおよびDuo）、ウィンドウでホストされていないXAMLサーフェス、シェル統合、混合フレームワークプロジェクト（xamlアイランド、GDIおよびWinUIミックス）、Hololens Spatial 3D、Rotating SurfaceHubsなど。

しかし、宣言型マークアップは、もはやそれを処理するための理想的な方法ではないかもしれません。 それとも、XAMLコンテンツとXAMLスタイリングをもっと分離する必要がありますか？ HTMLやCSSと同じように？

WinUIは、物事をそのまま引き継ぐだけでなく、今後数十年の計画を立てる良い機会のように感じます。

いいえ、要点はわかりません。 それは何も解決しません。
どちらかといえば、xaml拡張機能をすでに知っているエディターで問題が発生します。
私は毎日wpf、uwp、forms xamlを使用していますが、拡張機能が原因で混乱することはありません。

Xamlの要点は、ツールが簡単だということではありませんか？ ファイル拡張子の古代の考えに頼らずに、ツールでこれを理解することはできませんか？

つまり、一般的に、UIフレームワークで何も変更されていない場合、つまりXAMLのままである場合は、変更しないでください。

まったく新しいUIフレームワークであれば、問題はありません。

また、提案されたislands.xamlを使用して、アイランドのXAMLコンポーネントを区別したい理由もわかりません。 それはツールで何か違うことをするのでしょうか、それともソリ​​ューションの読みやすさのためだけでしょうか？

私の最初の考えは、私はこの考えが絶対に好きではないということです。 しかし、それが解決できる本当の問題がわからないかもしれませんし、要点がわからないかもしれません。

xamlを含むファイルがある場合は、それを.xamlファイルにします。 これまで、UWP.xamlファイルにWPF.xamlファイルとは異なる名前を付けたいとは思いもしませんでした。

次のことは、フレームワーク名が変更される可能性があるため、ファイル拡張子のフレームワーク名は適切ではないように思われることです。XAMLは4everXAMLです。

ですから、私の意見は次のとおりです。間違いなく.xamlを使用してください。

しかし、.xamlファイル拡張子のオプションは何ですか？
別の.islands.xamlファイル拡張子？ つまり、ファイル拡張子は、形式だけでなく、ファイルの内容を説明するためにも使用されます。 うーん...しかし、これの利点は、開発者にとってオプションにすることができることです。 使用したい場合は、ファイルを.islands.xamlと呼ぶことができ、ツールはさまざまなアイコンなどでそれを取得します。

別のデフォルトの名前空間も有効なオプションです。 しかし、それはツールにとって、それがどんな種類のファイルであるかを見つけるためにすべての.xamlファイルを調べなければならないことを意味します。 また、別のルート名前空間のために、XAMLダイアレクトが再び少し分岐していることも意味します。

しかし、今ではまったく異なる考えです。

私が正しく理解した場合、これらの変更はすべて、同じソリューションにプラットフォームを混在させるXAMLアイランドの場合にのみ本当に役立ちます。 WinUIを使用するだけであれば、すべてのXAMLファイルがWinUIを使用していることがわかります。 XAMLアイランドがWinUIのメインシナリオになるかどうかはわかりません。 過去にWPFが導入されたときは、WPFとWinFormsの相互運用機能もありました。正直なところ、WinFormsアプリケーションでWPFコントロールを使用している開発者はめったに見られませんでした。 代わりに、彼らは引き続きWINFormsでWinFormsを使用し、WinFormsの代わりにWPFを使用して新しいプロジェクトを開始しました。 また、WinUI 3についても同じことが言えるかもしれませんが、そうなると思います。 XAMLアイランドは最新化するための優れた方法ですが、私の経験では、開発者はWPF / WinFormsアプリでWinUIからの制御が確実に必要な場合にのみそれを行います。 そうでない場合は、古いスタックを続行し、新しいスタックで新しいアプリを起動します。 これは真実である必要はなく、単なる私の経験であることに注意してください。 :-)

つまり、プラットフォームのメインシナリオではない可能性のあるシナリオのファイル名を変更することについて話しているということです。 そして、それが私がそれが価値がないと思う理由だと思います。 WPF / UWP / Silverlight / WindowsPhone開発者が新しいWinUI3プロジェクトを作成した場合はどうなりますか？ 彼らは考えるでしょう

なぜ彼らは.xamlファイル拡張子を...に変更したのですか？

.xamlファイル拡張子を削除しないでください。

拡張機能を変更しないでください！

何年も前に、Avaloniaで.paml拡張機能を使い始めましたが、それが引き起こした問題のために、最終的に.xamlに戻りました。 、少なくともそれは何かです！）。

すべてのXAMLダイアレクトに独自のファイル拡張子があると予想する場合、XAMLを使用するすべてのプロジェクトは、ツールの100％を最初から作成する必要があります。ファイルの名前を変更するためのツールなども必要になります。毎回書き直され、クラスの背後にあるコードの名前も変更されます。

上記の@stevenbrixのように、ファイルが使用しているXAMLの方言を判断するための完全に良い方法があります。これは、ファイルの先頭にあるデフォルトの名前空間です。 最初のステップとして、ツールにこれを尊重させます。

次に、XAML言語サービスを開き、デザイナーと対話するためのAPIを提供すると、誰もが恩恵を受けることができます;）

かなりお願いします;）

しないもう1つの理由：UWPはすでに採用の問題に苦しんでいます。 名前を変更すると、「wpfとほぼ同じもの」ではなく、さらに別のテクノロジとして販売されます。
WinUI 3.0には、既存のuwpエコシステムに大きな打撃を与える変更を壊すという大きな問題がすでにあります。 異なるものをさらに追加しないでください。
それはまだxamlであり、さまざまなAPIセットにアクセスするだけです。これは、さまざまなUIフレームワークに使用してもc＃がまだc＃であるのと同じです。 使用できるコードとAPIは変更されていますが、それでも同じ言語です。

私は反対票を投じます、私は利益を見ません、ただ混乱を加えました。

しないもう1つの理由：UWPはすでに採用の問題に苦しんでいます。 名前を変更すると、「wpfとほぼ同じもの」ではなく、さらに別のテクノロジとして販売されます。
WinUI 3.0には、既存のuwpエコシステムに大きな打撃を与える変更を壊すという大きな問題がすでにあります。 異なるものをさらに追加しないでください。
それはまだxamlであり、さまざまなAPIセットにアクセスするだけです。これは、さまざまなUIフレームワークに使用してもc＃がまだc＃であるのと同じです。 使用できるコードとAPIは変更されていますが、それでも同じ言語です。

@dotMorten Ha、C＃でも同じ考えでした。 .xamlファイルを.winuiと呼ぶ場合、一貫性を保つために.csファイルを.wincodeと呼ぶ必要があります。 :-)

まだ何かが足りないのかもしれませんが、それは私にとってより多くの混乱を引き起こし、それの本当の利点がわかりません。

私の2セント、_。xaml_を使い続けてください。
発散するのではなく、団結してください。

WPFとWinUIの間で小さなXAMLスニペットを共有したい場合はどうなりますか？ いくつかの重複があるに違いないと思いますね？ それは共有プロジェクトの有用性を低下させるでしょう...それとも本当に大きな違いがありますか？ ほとんど同じ類似のXAMLである場合は、同じ拡張子を維持します。 形式が移行XAMLとほとんど異なる場合は、拡張子を変更する方が多少受け入れられる可能性があります。 本当の問題は、フォーマットがオリジナルにどれだけ近いかということです。

XAMLは、WindowsだけでなくiOS、Android、macOSなどを対象とするXamarinでも使用されます。

.xamlを.winuiに置き換えると、XamarinがXAMLファイル用に.xamlを保持し（iOSまたはAndroid用に.winuiを使用する理由）、UWP / WPF ...などのWindowsターゲットがXAMLファイル用に.winuiに移動する状況が作成されます。 。

TL; DR 1つのファイル形式/従来の2つの名前（Windowsの場合は.winui、Xamarinの場合は.xaml）、私には混乱します。

xamlのコンテンツの構文として、拡張子は.xamlである必要があります。別の拡張子は、混乱を招くだけです。
.winui.xamlのようなものに投票します

「.xaml」にとどまり、その強力な

私が言わなければならないのは、Microsoftには病理学的命名の問題があるということです！

そして、これは本当にそれらすべてを上回っています。

番号

同じプロジェクトファイル内にUWPXAMLとWPFXAMLを含める必要がある場合は、代わりに新しいCustom Toolを使用してください。

このようにして、ツールはXAMLファイルがUWPXAMLまたはWPFXAMLのどちらを使用しているかを検出し、msbuildターゲットを介してそれらを正しいコンパイラに送信します。

さらに良い方法は、XAML言語を標準化して、共通のコンパイラ、バイナリ形式、およびフレームワークライブラリを開発できるようにすることです。

それが私がそれをする方法です！

あなたが求めているので、それをしないでください。

ツールがファイルを読み取って違いを確認できない場合、WORSECASEは「.winui.xaml」などの必須ではない規則である必要があります。 ここでも、キーは必須ではありません。 xaml拡張ファイルだけで問題なく動作するはずですが、拡張ツールが不足している可能性があります。

この背後にある考え方は理解していますが、悪い解決策だと思います。
まず、WinUIはフレームワークの商品名であり、ファイル形式ではありません。 バージョン4で名前をUniversalUIなどに変更する必要があると誰かが判断した場合はどうなりますか？ ファイル拡張子とは異なり、ファイル形式とは異なるフレームワーク名で終了します。 それは悪夢かもしれません。

次に、既存のツールやドキュメントとの互換性が失われる可能性があります。 将来の開発者は、WinUIファイルが内部的にxamlであることを明確にできなかったため、xamlドキュメントを関連するものとして見つけることができませんでした。

第三に、Microsoft製品で使用されるUI言語をさらに断片化します。 Xamlの標準にさらに移行する必要があるので、製品はそれほど重要ではありません。 C＃はXamarin、Net Core、Windows 10、またはWPFで同じですが、なぜXAMLを変える必要があるのですか？

人々がプロジェクトを整理し、コードを整理して、混乱しないようにします。

json形式を使用します。 2020年です。

@rickydatta 2020年でも、WebはJSONではなくHTMLを使用してユーザーインターフェイスを定義しています。 HTMLやXAMLなどのマークアップ言語がUIの定義に優れている理由はたくさんあります。 JSONはいくつかの点で優れていますが、UIの定義には適していません。 UIにJSONを使用していて、データバインディング、静的リソース参照などの機能を構築しようとすると、JSONがまったく読めなくなることがわかります。 しかし、ここではトピックから外れているので、そのままにしておきましょう。 JSONが必要な場合は、新しい問題を作成して、コミュニティがそれにどのように反応するかを見てみましょう。 :-)

これのほとんどはすでに言われているので、私は本当にここでコメントすることを避けようとしました、しかし私は屈服しました。ごめんなさい。 私が弱い。

これをしないでください。

変更を加えたい場合は、マイナス面を上回る明確なメリットが必要です。

潜在的なメリットは何ですか？

• WinUIコントロールを完全に含む.xamlファイルと含まない.xamlファイルを持っている人にとっては混乱を避けることができます。
• ツールを有効にして、.xamlファイルの潜在的に異なるコンテンツを処理する方法を決定するのに役立ちます。

それでおしまい。
このスレッド全体を3回読み直しましたが、ここにリストされている他の潜在的なメリットはわかりません。

潜在的な欠点は何ですか？

• それは混乱をもたらすでしょう。
  -「この新しい拡張機能とは何ですか？」 「何を開ける必要がありますか？」 「…とどう違うの？」 「なぜ彼らはそれを変えたのですか？」
  -既存のUWPXAML要素とWinUI3要素を混在させる場合、一部のWinUIコントロールのみを含むファイルにどの拡張子を使用しますか？ それとも、この提案は、この機能がなくなることを意味しますか？ （ファイル拡張子を変更するように提案するだけで、すでに混乱とFUDが発生しています。ファイル拡張子などがまだ変更される可能性がある場合は、WinUIを、より安定するまで、あらゆる容量で検討する必要があります。 。何人かの人々が私にFlutterを調査するように言った。おそらく私にとってより良い未来はそこにある。）
  -既存のWPFアプリにおけるXamlアイランドのセールスポイントの1つについての私の理解は、XAMLを操作する際に既存のスキルと知識を再利用できることを意味するということでした。 この変更は、XAMLだけではないことを示唆しているため、学習する必要のあるもう1つのことであり、採用に対するもう1つの潜在的な障壁でもあります。）

• 不要です。
  -ソリューション内でファイルを分割したい場合は、すでに複数の方法でこれを行うことができます。さまざまなプロジェクト。 異なるディレクトリ; ファイル名のプレフィックスまたはサフィックス。 複数/サブ拡張を使用する; または、VSソリューションエクスプローラー内でファイルをネストします。 新しい拡張機能や、複数/サブ拡張機能の使用を全員に強制することが、これらのオプションのどれよりも優れているかどうかは明らかではありません。
  -[デフォルト]ファイル内の名前空間は、XAMLのどの方言が使用されているか、およびXAMLで何が可能であるかをツールにすでに示しています。 （この領域には、文書化されていない問題がある可能性があります。これは不可能ですが、その場合は、ファイル拡張子を変更することがその問題の最善の解決策である理由について、より多くの情報が必要です。）

• 履歴は無視されます。
  -以前は、WPF、Silverlight、およびWindowsPhoneを対象としたプロジェクトを含むソリューションを使用していました。 それらはすべて異なるXAML方言を使用していましたが、どれが使用されているのか、ファイル内で何ができるのかについて、私は一度も混乱することはありませんでした。 UWPおよびXamarin.Forms用のXAMLを含むソリューションを使用しましたが、この問題の背後にある仮定で予測された混乱は発生していません。 同様のソリューションを使用している他の多くの開発者とも話をしましたが、別の拡張機能を使用すると役立つと言う人は誰もいません。
  --XAMLにはさまざまな方言があることについて聞いたすべての批判の中で、ファイルの命名に基づく混乱はその1つではありませんでした。
  -開発者は、非常に正当な理由なしにファイルやプロジェクトに名前を付けて構造化する方法を説明するとき、一般的にそれを嫌います。 同様の内容のファイルを含むプロジェクトでの作業などのシナリオについては、ガイダンスと推奨/推奨プラクティスを文書化する方がはるかに優れている場合があります。
  -ファイルで複数の拡張子が広く使用されるようになったことがない大きな理由の1つは、ファイルエクスプローラー（またはOSが提供するピッカーやダイアログを含むファイルシステムのコンテンツを一覧表示するもの）が（既知のファイル拡張子を非表示にするように構成されています（これがデフォルトです）。 これにより、 MyClass.winui.xamlがMyClass.winuiのように見える可能性があり、ファイルが何であるか、どこから来たのか、なぜ表示されているのかなどについて質問や混乱が生じます。
  -複数/サブ拡張子を追加すると、ファイルの長さが長くなるため、MAXPATH関連の問題が発生する可能性が高くなります。 いつかこれは問題にならないかもしれませんが、私たちはまだそこにいません。 ツールが拡張機能に追加の6文字を必要とするようになったため、開発者がファイル（および2つは通常同期されているため、クラス）にわかりにくい名前を付けることを余儀なくされるのを見たくありません。

• これにより、ツール開発者の作業が増えます。 （マイクロソフトの内部と外部の両方。）
  -処理するケースが増えました。
  -文書化してテストするその他のシナリオ。
  -バグ修正と新機能に費やす時間が短縮されます。 現在のXAMLツールは他のテクノロジーに遅れをとっており、カスタムツールの作成が遅いと認識されているのに、なぜ新しいツールの作成を遅くするものがあるのでしょうか。

• 非常に悪い前例を作る危険があります。
  -これが発生した場合、現在のすべての.xamlファイルを.wpf 、 .uwp 、 .xamarinformsなどに置き換えることが適切でないのはなぜですか？ または、基になる名前空間が使用されている場所ではなく、 .xaml2006 、 .xaml20009 、 .xaml-uwp5が重要な問題である場合は、 （この場合のように）潜在的なメリットは最小限ですが、Microsoftがファイルの命名を提案する方法として多くの人に見られます。 （ここでの議論を見ただけで誰かがそのような提案をしなかったとしても、私は驚かないでしょう。）
  -サブ拡張子に基づいてファイルを処理するMSが提供するツールを認識していません（ただし、修正されてうれしいです）が、これを行うと、Visual Studio（およびWindowsシェルを含む他のツール）が必要になる可能性があります。これらのシナリオを処理できます。 次に、機能が利用できるようになると、複雑ではあるが不要な名前の提案が提案され、一部の開発者にとっては多すぎて、他の開発者にとっては混乱を招くような、さまざまな複雑な名前の提案を導入したいという誘惑を想像できます。

要約すると、この提案は、限られた状況で理論的利益のために混乱とより多くの作業をもたらすでしょう。 もしあなたがこれをしたなら、私はWindows開発をあきらめるでしょう。

あなたの声を貸してくれたみんなに感謝します。 聞いたよ！ 十分なフィードバックを収集したので、.xaml拡張子を変更することはできません。

エコシステムを断片化したり、サードパーティのツールを壊したりすることは私たちの意図ではありません（そしてたくさんあります）。 XAMLが言語であり、WinUI3がXAMLを使用するUIフレームワークであることに同意します。 これらすべての理由、およびその他の理由から、xaml拡張機能を引き続き使用することは理にかなっています。

私たちのチームはまだいくつかの宿題をし、後でコミュニティと相談する必要がある他の選択肢を評価する必要があります。 例えば：

1. 何もしない。 XAMLアイランドの開発経験はそのままになります：別のプロジェクトのXAMLファイル（おそらくこれは大したことではありません）。 WInUI 3は同じ名前空間を使用しますが、プロジェクトで使用される唯一のXAML言語であるため、問題ではありません。

2. 名前空間を使用して、XAMLに基づくUIを区別します。 現在、WPFXAMLとUWPXAMLは同じ名前空間を使用しています。おそらく、WinUI 3は、Xamarin Formsが実行しているような別の名前空間（ "http://xamarin.com/schemas/2014/forms"）を使用する必要があるため、コンパイラ、ツール、および設計者はファイルを区別できます。 反対に、これは方言を作成しますが、これは今日起こっています。 理論的には、これにより開発者はドキュメント/ブログからXAMLの例をコピーして貼り付けることができますが、残念ながら、名前空間を含まないサンプルがたくさんあります。

3. 何かをしなさい、しかし島のためだけに。 すべてのUIフレームワークを区別する必要はありません。 規則を使用できます。 たとえば、将来的には、XAML Islandを使用するWPFアプリで、特定のフォルダー（islandsフォルダー？）にXAMLファイルを含めることができます。 これは、UWPローカリゼーション（Strings / en-US / Resources.resw）に似ています。

フィードバックありがとうございます。 より多くのアイデアが成熟したら、新しい議論を開きます。

アイランドファイルのスニピットまたはDoctypeスタイルラインを含めることで、ツールを作成するのに十分なはずです。

.ui.xamlのアイデアが好きなら、それは良い妥協案だからです。 これは引き続き有効なXAML拡張機能であり、正しいエディターとアイコンを選択するのにも役立ちます。 また、タイプを見つけるためだけに数十/数百のXAMLファイルを開いて解析するよりも効率的です。

@ marb2000 WinUI 3は、XAMLを使用するUIフレームワークです。

WinUI 3は、XAMLを使用できるUIフレームワークです。 XAMLを使用する必要がなく、XAML言語に依存する必要がないためです。

XAMLが言語であることに同意します

これは良いことであり、XAMLと呼ばれる多くの名前空間はWinUIで名前を変更する必要があります。XAML言語とは関係のないものです。

UWPのディエンファシスは、目撃するのに苦痛でした。 これで、チャネル9でUWPコンテンツを検索すると、Xamarinコンテンツが表示されます。 それはそのような明白な策略です。 UWPを他のものに変形しようとするのをやめてください！ 再投資し、ダブルダウンして、それを機能させます。 UWPはコース修正を必要とせず、XamarinチームとOfficeチームが参加する必要があります。 マイクロソフトの内部政治がUWPを殺しています。

@Noemata公式メモですか？