[
Lists Home |
Date Index |
Thread Index
]
That it confuses them is not too surprising. Abstract
to concrete didn't work too well in music theory either
where, for historical reasons, they taught counterpoint
before teaching harmony (when composing, it is a lot
easier to go from a chord progression to a contrapuntal
derivation than the opposite, but historically, music
emerged from single lines, so...). Still the dilemma
is to keep their fickle fingers off the keyboards of
implementation fate until they understand their options.
I like those examples, Aaron. Good job as usual.
I think getting people to accept a document model
may be the critical piece. (no duh!)
It seems one shouldn't dive too deep into the syntax
without acquainting them with the infoset and at least
saying: "XML Is Syntax. Full Stop. XML Frameworks
are something different. Don't get too settled into
your convictions until you see my provider examples.",
and then give them the overview. Then the
"Just show me the code" mentality can be made to
work to the instructor's advantage because they
see the code and realize that syntax is not being
emphasized and that they need to adjust their paradigm.
I'm seeing the other side of the damage where folks
are refusing to let go of old technology because they
can't see the advantage of slightlyStrongerASCIIFiles
and that is as deep as they get before they make
up their minds.
len
From: Aaron Skonnard [mailto:aarons@develop.com]
Len wrote:
...
> Is there a confusion between loose coupling
> as an API/data model and loose coupling as file
> types on the wire? While both are viable, I
> wonder if we would have the same confusion if
> the InfoSet were taught before the syntax.
It's interesting you say that. Back when we first started teaching our
first XML courses at DevelopMentor, we started with the Infoset as the
foundation followed by serialization at a later point. We found that the
approach actually confused more developers than it helped and generally
got the course off to a bumpy start. Since then, we've applied the
"start concrete, move abstract" approach, which seems much easier for
developers to grok. This seems true for most technologies, actually, not
just XML.
What really seems to help developers appreciate the difference between
these coupling models are good examples of "XML providers" where there
are no angle brackets involved. I've written several in .NET that expose
the file system, registry, zip files, dlls/exes, etc, as logical XML
documents. Then you can write XPath expressions that looks like this:
/mycomputer/c/temp//samples/book.zip/chapter1.doc
/mycomputer/c/invoices/invoice.xml[sum(//price)>1000]/@ID
Obviously, these XML providers not only give you XPath and XSLT
integration but also integration with .NET's DOM implementation.
Along these same lines, the built-in SQL Server 2000 XPath integration
is another great example that illustrates the concept.
|
