pre-defined xmlns prefixes

[StephaneDelcroix]

Description

Building on #28849, and even if the user choose to pack most of the xmlns into the global one #28846, we might need prefixes to disambiguate name conflicts.

Say we have this xaml

<ContentPage>
    <Label x:Name="mauilabel"/>
    <Label x:Name="mylabel"/>
</ContentPage>

stay with me. say that the default xmlns is the global one (#28849), and aggregates (#28843 , #28846, #28847) maui and your own controls, AND that a "Label" type is defined twice.
the parser will complain, and ask for disambiguation.

in this case, we consume 3 xmlns prefixes, without defining them. they are automatically fed (like the default one) into the parser (not making this an invalid xml), with the prefixes found as defined by XmlnsPrefix attribute

<ContentPage>
    <maui:Label x:Name="mauilabel"/>
    <local:Label x:Name="mylabel"/>
</ContentPage>

This is NOT invalid XML. It's an invalid xml DOCUMENT, but it's a valid xml FRAGMENT. All the tools used for parsing xml will keep working, provided the default xmlns is fed into the parser.

This is an OPT-IN feature, and you can choose to use it or not. if you declare your own prefix, it will be used instead of the predefined one

(Public) API Changes

/

Usage Scenarios

/

Backward Compatibility

/

Difficulty

Low

[mrlacey]

This is NOT invalid XML. It's an invalid xml DOCUMENT, but it's a valid xml FRAGMENT. All the tools used for parsing xml will keep working, provided the default xmlns is fed into the parser.

Doesn't this also require the parser to know which default namespace to include? - And so need to know how the MAUI tooling determines this?
It might be ok for the MAUI tooling, but would break (or require updates) for anything else that tries to parse the file.

[StephaneDelcroix]

@mrlacey if you use 3rd party or custom tools that haven't been enhanced to support this, you can choose not to use the feature, and declare the xmlns as usual. tools will need to be updated, and the information on how we handle this is public, as part of this set of specs, and the PRs that will be associated

[mrlacey]

I'm glad to hear details of what tools will need to do will eventually be included here.

Two immediate scenarios come to mind that cause me some concern:

1. If this starts a series of changes that lead to external tools needing to be regularly updated.
   If many changes are possible, can they be bundled together, rather than slowly included over a series of releases, to lower the impact on other parties?
   Can details be clearly communicated well in advance so that tooling has the chance to be updated prior to the feature being released.
2. Someone adopting this new feature but only finding out it causes them a problem when a tool that runs as part of the CI pipeline fails because it doesn't (yet--hopefully) support the feature.

[StephaneDelcroix]

we're still talking about hypothetical 3rd party tools...