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.
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.?
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! ;-)
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.
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).
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.
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).
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.
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.)
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.
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]