It’s just data

XAML is for humans

Don Box: Today, the data needed to initialize an object graph is hidden behind imperative statements in your programming language of choice. That makes it difficult to tease out of the rest of your program without weird markers in the source code to delimit the structure of your code into recognizable pieces.

I buy this part.  I don't buy the Man vs Machine angle.  If you want to write some queries over this data, the schema had better be understandable by mere humans.  And if you want to write a transformation, you had better be prepared to wallow in the instance data, as that's how you will have to debug it.

My previous post on this subject had more to it, but I chickened out and didn't post it.  What the heck, I could be wrong, but... here's essentially what I said.

What I can piece together is that somebody was designing a visual composition editor targeting the traditional VB crowd.  And ran into limits in the ability to round trip generated source code that had been modified by humans.  Attributes helped, but weren't enough.  What was needed was some real structure.

So, that person chose to serialize that data separately.  Such is not new, other visual composition editors have done this for years.  However, given that it is 2003, the choice was made to serialize that data as XML.  This too has been done before.  Furthermore, I gather that that person wasn't exactly a connoisseur of XML, but merely viewed it as just another data format. 

However, an inevitable consequence of having chosen an XML format is that the development team will receive a lot of "help" in designing the format.  Both from within Microsoft and from the peanut gallery.  Whether they want it or not.

I've been on both sides of that particular equation.

I could be wrong about some or all of this.  Even if I am largely right, I can never be 100% sure.  However, if my guesses are correct and some of the internal discussions are going the way I expect that they have been, all I can say to Don is:

You go girl.


Sam,

You're correct in that the more "human readable" XAML is, the better.

I haven't tried this yet, but from looking at the generated code, you will definitely be able to debug through XAML files, the same way you can debug through ASP.NET files today.

BTW, you are absolutely correct. The transparency of XML formats makes everyone a critic. 

Our experience with the WS-* world made this readily apparent.

DB

Posted by Don Box at

you will definitely be able to debug through XAML files, the same way you can debug through ASP.NET files today.

Would that involve working in XAML's XML1.0 representation directly or using a nice tool to work with XAML indirectly, most likely through visual designers in their IDE of choice.?

Posted by Sam Ruby at

sam,

i still need cliff notes to read most of your posts, but i try to keep up with you as much as i can.. 

i'm sure that this is a silly, stupid question so bear with me here...is there a way to track referrals to rss feeds?  i'm not a site meter addict, but i am just interested in knowing how this works...

remember i don't speak your language, so keep it simple!  ;-)

Posted by jen at

Question from that gallery: what I'm wondering is how far will XAML eventually stray into being a Turing complete language in itself?  Don's four points listed here  seem reasonable but is that where the line is being drawn?

Have seen other attempts to define something like an XML based language independent language (e.g. http://www.meta-language.net [erratic uptime]) and the result typically seems to be a great idea in theory which no one's going to touch in practice (why generate Java with XML when you can skip the XML?).

That said, with the right tools (IDE) and marketing, I guess anything is possible. Mozilla's XUL has neither and after three years, adoption hasn't happened.

Posted by Harry Fuecks at

Jen, I think the answer to your question is no.  I've responded offline with examples of the types of information that can be found (while this information is readily available, I'm not sure you want it published).

Posted by Sam Ruby at

Harry, it looks to me like XAML was designed to solve a specific problem for a specific tool.  In particular, allowing someone to edit a combination of visual controls after they initially created it.  Reverse engineering Java (or C#) code for this particular application is suboptimal for both humans and machines.

What Don and others are trying to do is make suggestions that will make it easier to allow other tools to add value.  And you can call me an optimist, but I am confident that if people took the time to study XAML and make constructive suggestions, that they would be listened to and accommodated if at all possible.

P.S.  From what I can see MSFT doesn't really need to market this - my awareness of XAML is entirely due to the coverage by the blogosphere by non 'softies.

Posted by Sam Ruby at

If I'm understanding XAML right, it seems very similar to Apple's ProjectBuilder/ InterfaceBuilder/ WebObjects tools.  They too generate code and yet are able to have either or both the machine and human edit the code.  One difference I see is that Apple's tools work on plain text source (.C/.h, .java, Makefile) and only the GUI object-graph is serialized (in XML nowadays, I think, used to be in a binary format).

Posted by Ken MacLeod at

From my days as a NeXT hack, I could swear there was a .mib file that contained the layout info for a given panel. Did Apple move away from that?

DB

Posted by Don Box at

Don, what kind of transparency issues did WS-xxx show up?  Other then the fact that they're proprietary, I mean.

Posted by Rich Salz at

Rich,

People often confuse surface area syntax with operational semantics.

Both are important but their distinct.

DB

Posted by Don Box at

I've historically been "a late bloomer" and one step behind the crowd.  Just recently heard about XAML, and have JUST started getting into beginning of Shelley's Practical RDF book (bought at Borders, natch).

But I've wondered for a while if RDF may not be a good fit for this kind-a stuff, even though I don't understand but half.

I wrote a code-generator in late-70's, early-80's on a 64K Univac mini with no virtual memory.  Not boasting, as never did anything with it, but I do have Some Very crude understanding of the underlying concepts, and read James Martin's Programming without Programmer's (or something close) way back when.  Don't understand much-a the lingo these days.

I'm just guessing, granted...  But seems like code would be a good (if not ideal, but dunno) data-fit for some kind-a analysis language/tools combo like RDF.

Posted by JayT at

RDF looks like a good fit for most applications of XML.

People have had mixed results trying to actually apply RDF in the wild.

DB

Posted by Don Box at

I'm way past tired, and don't understand, Mr. Box.  Can you elaborate, and maybe some comprehension will seep in tomorrow.

The RDF I've seen is just a transform of XML (fer as I ken tell).  Seems like a relatively simple transform, but have not written any parsers myself to say for sure. 

I keep hearing of RDF applications, but I've not ran across them much at all and I read a fair bit.  How widespread are the implementations, then??  And what do you mean "in the wild"??  Are business apps considered "in the wild"??

(No sarcasm intended, but like I said at top... so may have come across wrong.)

Posted by JayT at

I'm the last guy you should be looking to for pointers to RDF apps in the wild.  My allusion was to XML apps in the wild that tried (and failed) to adopt RDF.  RSS is one of the most visible examples.

Despite my enthusiasm for RDF in the previous century, I've stopped waiting for a miracle and have moved on.

You might look at Tim Bray's blog for more history and context.

DB

Posted by Don Box at

Thank you, DB.  I have and will continue to do so.  Prefer reading to writing anyhoo...

Posted by JayT at

Don,
Nope Apple is still using a serialized interface (NIB file, which stands for Next Interface Builder file - if I remember correctly). Originally this was a binary file that stored all references to widgets and how they connected to the different class file methods. Now, I believe it can store this info in XML.
[link]

-warner

Posted by Warner Onstine at

Warner,

Thanks for the info. I'm glad my memory isn't totally off base (I remembered 2 of the three letters and was only off-by-one on the remaining one).

DB

Posted by Don Box at

</table></b></span></body>

Posted by nbmcb at

Add your comment