Open insinfo opened 7 years ago
Oh god no. If you want a spec to move REALLY slow, this is how you do it.
A Standard does not need to change every day, a standard has to be stable, consistent, and extensible
Sure it does. If you want to innovate and improve the spec several times a year (windows has two yearly releases) you want the implementors to run the show and not be held up by a standards body that often takes years to complete. I don't really get what the value add is. On the contrary it would remove the need for this public github repo and take away much of the input we get to provide.
The process of creating a pattern is a bit slow, but it has been much faster now than it was before, for example ISO established C++ 14 in 2014, and now in July it is going to release C++ 17, And C++ 20 is already planned for 2020. Another example is JavaScript that had a version every 3~ years. Also while a standard is in development, it can already be implemented in parallel, this happened with the C++ that the majority of compilers already implemented before being released. This also happened with HTML5 most browsers implemented many things of the specification before launch. That is when the official release was already implemented in most browsers. In addition, this delay of the process of creating a standard is good so that the time of the current version is implemented in several environments. Provided it acts enough disclosure, incentive, resources, robustness and stability.
Right. I can't think of a single xaml developer who's OK with a 3 year cycle. That would mean the first draft if v1.0 would be 2020 the earliest. No thank you
I mentioned above is complex programming languages like C ++. Since a specification of an XML-based markup language I believe will be much faster. And because there would be the urge to change a language in a time less than a year. What can and should change faster are the implementations of the specifications of a standard, APIs, Frameworks, IDEs, iso can change up every day bringing bug fixes and performace improvements in addition to new features.
You still haven't answered the why. Why is this a good thing? However you spin it, it adds unnecessary Overhead
Because I already said
think this would attract more companies and developers to adopt this standard in their software development and designer solutions, such as: Nuklear, Embarcadeiro, Qt Company, RemObjects, Guiliani, JUCE, LiveCode, wxwidgets, IUP, GTK, fltk, EFL, CEGUI , Xvt, CEF, Adobe, Google and others.
What I mean by that is that it will fuel and enrich the XAML ecosystem.
Oh god no. If you want a spec to move REALLY slow, this is how you do it.
What, I thought we embraced challenges? What's more challenging than the test of time? 😆
Is this something we could aim for after a v1? It would be nice indeed but I am also wary of the costs/risks in doing so. Maybe after the cements settles.
@Mike-EEE But that is my intention with this post, It would be good if after version 1.0 is set forward towards an international standardization. This discussion is very enriching because here we can advance to many good ways, debating ideis, doing questions this is very good.
Is this something we could aim for after a v1? It would be nice indeed but I am also wary of the costs/risks in doing so. Maybe after the cements settles.
debating ideis, doing questions this is very good.
With you 100% on that, @insinfo. I think the wonderful aspect of this repo/Standard is that MSFT clearly had one idea for where to take this (and probably still do), while the community has a completely separate idea. Hopefully we can find agreement on something that we can all be proud of as we head into future versions.
In any case, this is very much a part of the creative process and I for one appreciate the creative energy around it. Hopefully it will inspire some serious super power around these parts. It's been dead for far too long. 😛
CSS and HTML are much more delicate things to change as it affects billions (not just developers and end-users as well). And any change in the pattern has to be done very carefully. But each case is a case, a markup language for graphical interface development will be much faster to define a new standard because it does not affect the end user, even though the standards nowadays have been released much faster, see case of C++.
I agree with @insinfo, that making it an international standard would be beneficial. It does slow things down a bit, after all more people means more discussion, but that is just the reason why it pulls in more adopters. If only the implementers have a say in what makes it into the language and what remains left out, "outsiders" will be much more reluctant in implementing, adopting it.
Implementers can always go ahead and implement "TS"-es (Technical Specifications, the prototype implementations of future features to come) and if they are of sufficient quality, they will make it into the next version as-is and can be used ahead of ratification.
How does this relate to Microsoft?
@MathiasMagnus Very good argumentation, in addition to an international and open standardization, besides mair adoption in the market, the ecosystem of related XAML technology will be more valued and eventually the developer will also be more valued
Another thing with XAML as more embraced standard is you won't have european parliament members trying to push for action against MS for allegedly trying to kill HTML and the web etc. with their own closed XAML tech (they had been suggesting that against Silverlight in the past in fact). Or maybe they still would, god knows what they're thinking...
@birbilis considering ecma for C#, xaml is with possibility
It would be nice if XAML were an international open standard supported by ISO, ANSI and ECMA. I think this would attract more companies and developers to adopt this standard in their software development and designer solutions, such as: Nuklear, Embarcadeiro, Qt Company, RemObjects, Guiliani, JUCE, LiveCode, wxwidgets, IUP, GTK, fltk, EFL, CEGUI , Xvt, CEF, Adobe, Google and others.