Short XAML syntax on Short XML syntax

[hsk]

XML is wonderful, however, there is room for improvement.
SGML used in HTML is complicated.
I think Extended XML (XXML).
XXML is very simple XML like language.
But, XXML has the schema as shown in Fig 1 and Fig 2.

XXML implementation writing Scala language is here.

If you don't mind, please consider XXML support for XAML Standard.

thanks, h_sakurai.

<schema>
<start>exps</>
<rule>
  <name>exps</>
  <rep>exp</>
<rule>
  <name>exp</>
  <call>table</>
  <call>text</>
<rule>
  <name>table</>
  <tag>
    <name>table</>
    <call>tr</>
<rule>
  <name>tr</>
  <tag>
    <name>tr</>
    <call>td</>
<rule>
  <name>td</>
  <tag>
    <name>td</>
    <call>exp</>

Fig 1. XXML Schema example

<table>
  <tr>
    <td>aaa
    <td>aaa
  <tr>
    <td>aaa
    <td>aaa
</table>
<table>
  <tr>
    <td>aaa

Fig 2. Using XXML Schema example

[GeraudFabien]

I thinks the main goal of an interface is to ask people implement it. XAML standart is like a big interface in code. If you start to change the base some project will not accept the load to implement or will lose time to implement it. WPF and uwp are not the only one in the dev ecosystem. Such change need to come from a big interest. If you want somethinks like that you may make a tools like "ammyui" compile into XAML.

[hsk]

Thank you your comment. I know this project is XAML library project. but, I think about short XML syntax when I think about XAML.
AmmyUI is good project, but AmmyUI is like JSON. I hope XAML like short XML syntax.
XAML is not good, because XAML syntax is long, because XML syntax is long.
I hope XML like short syntax, not JSON like syntax and not YAML syntax.

[hsk]

I found RELAX NG Compact Syntax
http://www.relaxng.org/compact-tutorial-20030326.html
but this is not like XML or HTML.

https://en.wikipedia.org/wiki/Simple_Outline_XML

SOX is like YAML.

[hsk]

I think the advantage of HTML over XHTML is the possibility of omission.

[MovGP0]

if your intent is to do less typing, then why not just use something like HJSON?

XAML:

   <-- this is my button --> 
   <Button x:Name="MyButton"
	   Content="My Button"
	   Click="MyButton_Click"
	   Command="{Binding MyButtonCommand}" />

HJSON:

   # this is my button
   { Button : {
           x:Name : MyButton
	   Content : My Button
	   (Click) : MyButton_Click
	   [Command] : MyButtonCommand # Angular inspired syntax for bindings
        }
    }

[birbilis]

ahem, XAML looks much better, esp if some shorthand binding mechanism was added

[GeraudFabien]

The only thinks i talk about is a way to implement what ask without using Xaml-standart. By using à compiler that compile into Xaml or baml. It will be more efficient and free to add language specific feature.

[birbilis]

could fork AmmyUI if it's code is available
http://www.ammyui.com/2017/01/04/ammy-modern-ui-language-for-xaml-platforms/
and/or convert from your DSL to AmmyUI's using regular expressions

btw, here is a XAML to Ammy converter, could change it to make your-own-XML to Ammy one
https://github.com/AmmyUI/XamlToAmmy

note that AmmyUI has support for WPF/Xamarin.Forms/UWP/NoesisGUI targets already
http://www.ammyui.com/

[mossyblog]

XAML and JSON is a bad idea, as the nature of XAML is quite verbose and implication that tooling partners would have to factor in duck typing over structured XML is a deterrence.

If you then infer that JSON follow a set naming convention then its really not a JSON moment and more of a JSD? which again means you have to backfill it with the vocabulary around its implementation which negates the idea of what XAML is.

[Mike-E-angelo]

JSON is a terrible format for configuration; that is not its intent. However, there are qualities about it that are admirable and that is what people are drawn to here with Ammy. There is certainly a difference between describing objects and the format they are described/stored in.

Hey @gulshan I keep thinking your ideas/efforts with dotnet/roslyn#16648 could possibly tie in well with this new Xaml Standard. Tagging you here so you are aware and can participate accordingly, if you aren't already. :)

[birbilis]

btw, I don't like the idea of a C# notation format instead of a languaage agnostic one for .NET

but being able to convert XAML to an imperative format that constructs a UI graph can help in cases like this (where WPF/UWP fall short compared to Silverlight): #100 (unless they decide to fix the issue they could use this conversion to compile/inline XAML used in ancestor UserControls as a workarround)

[Mike-E-angelo]

@birbilis I believe the idea is to have it as a certain format by default (I myself am partial to XML, even though it is technically a "language"), but being able to align it to any format as long as there is a provider. At least, that is how it should be.

I would also caution the use of this for exclusively UI-graphs. That is how things like UWP happen. 😉 This can be used to create any POCO, really. Which was the fundamental power and appeal of Xaml from the start.

[Duranom]

Xaml should stick to its current, any other format should be a third party implementation.
Also from please note that Xaml as it is now is very easy to learn and understand for non technical people, a lot of designers, consultents and managers are fast to understand to what everything means and making it shorter like with the suggested formats removes that.

Xaml should and must be aimed for more than technical people, actually technical people should in the end be more assisting. When you remove them from the picture we might as well throw XAML standard and any implementation away.

[Mike-E-angelo]

100%, @Duranom! The value in a code-agnostic, designer-friendly format is that it is ultimately cheaper to develop, manage, and maintain from a resource management perspective. If I run a business and I have to hire/aquire a C# developer/resource to maintain a deployed application, vs. one that requires someone who simply knows XML/JSON, we're looking at the difference between $50-$75 per hour to do so. Even greater if the XML/JSON is tied to a pretty designer surface that does most of the work for the resource having to work with it.

This was the promise of Xaml, in that it facilitated and assisted in the tedious and expensive workflow process between developer and designer. However, there is conceptually nothing stopping this same principle in being applied beyond this (e.g. DevOps workflow as alluded to above).