• From: Rick Jelliffe <rjelliffe@a...>
• To: "xml-dev@l..." <xml-dev@l...>
• Date: Mon, 24 May 2010 13:59:27 +1000

Liam R E Quin wrote:
> On Sat, 2010-05-22 at 09:32 -0400, Costello, Roger L. wrote:
>
>   
>> Here's a pathway I have found for learning the XML technologies:
>>
>> http://www.xfront.com/XML-courses-curriculum.gif
>>     
>
> This is a pretty weird way of teaching, I think
>   
I don't mind it. It is not dissimilar* to our courses at Allette.

We find with out markup courses over the last 18 or more years that

1) * It is really important to tailor the course to the set of students: 
using their schemas to make up examples for example. Often students will 
have to use a standard schema, eg ACORD or ANZLIC that is the ultimate 
cause of their attendance. (I.e. it is important to determine and 
satisfy the client's ultimate business requirement: doing your course is 
not a business requirement in itself!)  Or rearranging the topics to 
cover their concerns early.

2) It is really useful to schedule in foundation material (XML encodings 
for example) because often management has booked more advanced courses 
on the assumption that the knowledge that developers gather willy nilly 
somehow covers the foundation.

3) It is really important to have the courses taught by people of the 
same background as the students: developers teaching developers, 
managers teaching managers

4) You cannot have too many exercises or quizzes

5) Standards are more important than implementations

6) The software engineering implication of the standards are more 
important than the minutae of the standards: for example, with XSD, the 
most important issue is what impact it has on a system for robustness 
and agility if you allow data binding in the door, and the different 
tradeoffs for data-binding used internally (OK) and for public data (not 
OK): which comes down to the whole issue of when eXtensibility is 
appropriate.

Within that, I don't know that order matters so much. For example, while 
XSD (1.0 at least) has little overlap with Schematron, it has such a 
mind-share that can be useful to establish XSD's weaknesses and 
strengths first, and then show how assertions 
compliment/compete/enrich-the-solution-space with grammars, and then 
discuss issues such as how maintainability may be compromised when a 
large schema does not implement a separation of concerns between storage 
issues and business rules. (Which comes back, in turn to Conway's Law.)

So while the programmer language issues with Schematron of course rely 
on XPath, the software engineering issues of Schematron belong to schema 
and reporting languages.

Teaching markup technologies outside the context of software engineering 
is no favour to the students or their employers.

Cheers
Rick Jelliffe

P.S. There is no reason to teach XSD types in the context of an XSLT2 
beginner's course. You would not want to give your clients the 
impression that typed-based systems were the only way, or even 
necessarily the preferable way, to do XML. I have recently come across 
clients who thought that it was impossible to build XML systems without 
having an XML Schema: how 2003 of them!

• References:
  • A path to learning the XML technologies
    • From: "Costello, Roger L." <costello@m...>
  • Re: A path to learning the XML technologies
    • From: Liam R E Quin <liam@w...>