PASSED IBM 141-X ML - 76%

[ZEESHAN AZIZ]

Well, I can not believe it. I passed the exam today as well, with a score of 76%. Well, three guys, one day, same score: What a coincidence.

Right now, I am at work. I will jot down my observations about the test this evening, and will post morrow morning. Congrats to my colleagues, who share this happy moment with me.

[Jayadev Pulaparty]

Congrats Zeeshan. This is truly coincidental

[ZEESHAN AZIZ]

Ok, here are my observations about the test.
MY APPROACH:
On the very outset, I would say my prepration was not very thorough. Being London based, I hardly get any time for prepration. My prepration was based on flipping through 3-4 pages of xml stuff on my way to and from work, for past one month. I did study for the exam for about 4-5 hours during weekends.
My strategy for prepration was that for first two weeks, I focused on getting depth. So cleared my concept on XSL, Schemas, DTD. In second phase of my prepration, I tried to gain breadth, by focusing on mock exams, and java ranch discussions, to get a flavor of sort of questions being asked in exam.

Here are some of the tips for exam.
1. I find Skonnards' XML Quick Reference book (which is freely available online) highly relevant to the exam. It cover all the topics, and highly recommend using this book.
2. I agree with what has been said in the past two posts, and will add the following.
3. Know XPATH in and out. You must be familiar with facts like whether *[@*] will select child node or all the descendant nodes.
4. An idea of which function is required to return root element. You must know Document(), node() etc functions very well.
5. XML Mock exam case studies. Read them very well. Same case studies are repeated in real exam, however questions are different. I got Product-SKU (141 NEW MOCK EXAM) case study and Companies wishing to produce financial reports etc etc (141 NEW MOCK) studies. Now if you are familiar with a case study, you can save a minute or two in real exam.
6. xml rendering, never take light the fo:block elements and related stuff.
7. And I guess, if you are visiting this forum frequently, you know which technology to use for serial processing and which for cross searching.
8. ParserAdapter, yeah, I got it too. I could not got any mention of this class in any of the reference stuff I have got. So I said, it is for SAX1 TO SAX2 conversion. Nay sure whether it is right or not.
9. XSL Templates know the basic stuff. For instance, you must know that.
<Temp> -5 <Temp>
know to retrieve the value using xsl template like
<xsl:apply-template select=number (//temp) I think you must know the reason why such approaches will not work.
10. I got a very boring case study, one which can easily drive any one to sleep. I never went through it. Associated question was about DTD modelling. And good for me, 3 out of 5 choices were absurd. That saved me reading the case study. Only basic knowledge of DTD was required such as <Element myElement CDATA> is illegal.
11. As discussed before, leaf nodes that can not contain child, is a stuff, worth giving a read.
Well, I hope that would help to give you some idea that exam is very very close to the IBM Mock exams. Do IBM 140 AND IBM 141 (old and new) exam thourougly.
Hope that helps.

[Svetlana Petrova]

Congratulations, Zeeshan!
It is a great coincidence for all 3 of us to have the same score!
Yeah, I agree it's related to our studying techniques!
Yep, I remember I had this one too:
<Temp> -5 <Temp>
<xsl:apply-template select=number(//temp) />
And the one listing nodes and asking what are the nodes without leaves.
And I'm really glad that at the last day before the exam I looked back to XSL:FO (XML in a Nutshell) to refresh my memory. It helped me to answer the question about what are the block tags from the list of 5 of them.
And I recall now another question about which statement is true about "following" axis:
- all nodes excluding "preceding" axis;
- all nodes below context node (not including descendants, namespace, attributes);
I don't remember other 2 answers, but they looked wrong (too me at least ).
And the 2d one is exactly a definition from TR:
"the following axis contains all nodes in the same document as the context node that are after the context node in document order, excluding any descendants and excluding attribute nodes and namespace nodes".
The 1st answer is confusing. You could think it might be right, but it means that the "self" is included too, which is wrong. So I know I picked the right one.
Congratulations again!
And good luck to all others!
Svetlana.

[Himal Chuli]

Congratulation ZEESHAN!

[Valentin Crettaz]

Nice shot ZEESHAN

[satya uppaluri]

Congratulation ZEESHAN!
Satya

[John Wetherbie]

Congrats!

[ZEESHAN AZIZ]

Thanks John, Satya, Valentin, Choli and Petrova, JayDev for your congrats. It is highly appreciated.
I would like to acknowledge the fact that I learned a lot from your posts.
Well, it appears that IBM has a limited pool bank of Questions, as they keep repeating. Well, I read in almost 10 posts or so, that parserAdapter question is asked.
Now I am planning to proceed with MCSD.net certification, and intend to work on web services for mobile communications, during my free time. Thanks all, this forum helped me a lot, both during SCJP and IBM XML certs.

[Parth K]

Congrats Zeeshan on your success.
I was trying to find the following book mentioned by you -- "Skonnards' XML Quick Reference book " but was unsuccessful. Can you give me the exact URL where I can find it on the net.
Thanks.

[Roseanne Zhang]

http://www.develop.com/books/essentialxmlqr/

[ZEESHAN AZIZ]

I guess you have to first register, before you can access the book. I downloaded the book on my laptop, and read it once, and than used index for quick searching, whenever I encountered any problems. This book is short, precise, and talk business, from exam's point of view.

[Ashik Uzzaman]

Congrats Aziz...
Good discussion on your approach to the exam.

[Scott Duffy]

Congrats Zeeshan,
Great coincidence on the score.
I too may persue the MCSD.NET certification next. I am kicking myself though, since Microsoft kept sending me invitations to take the Beta exams for free, and I never went...
I think there still might be time for me to take the Solutions Architecture beta - next week I believe.
Scott

[ZEESHAN AZIZ]

Well, best of luck with your beta exams. Well, I was wondering whether the results of this exam would count towards your mcsd.net cert
I was one of the organiser at Application Development Conference (October) in London. And was really impressed by Microsoft marketing strategy. Though I am not a great fan of draggy droppy pointy programming approach, but I tell you .net is serious stuff. And these guys really know how to sell their stuff. I think that is one reason of their sucess, and that is what convinced me to go for mcsd.net cert.
Thanks Zaman and Scott, and best of luck with your endeavours.

[Dave Matthews]

What does *[@*] return, is it all the attributes of all the descendant nodes? Also what are the advantages of variables vs params?

[Jayadev Pulaparty]

Answer to one of your questions -
<xsl:template match="*[@*]">
This selects all the elements '*' that have one or more attributes, i.e., the attribute node set "@*" is non-empty

[Roseanne Zhang]

Jayadev,
I think when you say "all the elements", you actually mean "all child elements". Except that, it is correct.
[ October 30, 2002: Message edited by: Roseanne Zhang ]

[ZEESHAN AZIZ]

Well, major difference between xsl:var and param is that you use xsl aram during run time. I will say search posts within last 30 days, and you will find relevant discussion

[Jayadev Pulaparty]

Rosseane,
I expected to hear from you . Just my intuition. The following is what you said -

I think when you say "all the elements", you actually mean "all child elements". Except that, it is correct.

When i say "all elements", i mean all element nodes. What is it to do with child elements or parent elements? The wildcard * matches any element node, no matter what. Please clarify any of my (mis-)conceptions.
Thanks.

[Roseanne Zhang]

* is the same as child::*
//* is the same as all elements

<xsl:for-each select="*[@*]" >
<xsl:number />
<xsl:copy-of select="." />
</xsl:for-each>

Use the above code snippet on any your XML tree with more than one generations. See how many numbers will be printed out. Then you will know what I'm talking about.
You seems kind of unhapppy with my nitpicking. Sorry, my posts are terse, since I don't have time. Huge busy on the job.
I'm very new in IBM XML 141 test, and have learned a lot from others posts including yours.
Thanks a lot!
[ October 31, 2002: Message edited by: Roseanne Zhang ]

[Ron Newman]

I believe that "//*" is illegal as the value of an xsl:template "match" attribute. Only the child:: and attribute:: axes (or their abbreviations) are legal there.

[Jayadev Pulaparty]

Roseanne,
*[@*] is undoubtedly elements and not child elements according to me. This is why -
It all depends on what context you used it in.
As per your example - <xsl:for-each select="*[@*]" > here it means the child elements, no doubt.
But as per mine, <xsl:template match="*[@*]">, this means all the elements that have attributes.
Hence when they mention "*[@*]" in the question without putting it in context, i think the more generic answer would be element and not child element. Please correct me if i'm wrong.
Thanks.

[Sameer Amte]

I think *[@*] does refer to child elements which have attributes. i.e; child::*[@*].
This is because child axis is the default axis for an XPATH expression. I have tested it with
xsl:template match="*[@*] and it does return all child elements that have attributes.
Regarding the usage of //* (Ron's comment), this is perfectly legal. Here's a quote from the Spec.
A pattern must match the grammar for Pattern. A Pattern is a set of location path patterns separated by |. A location path pattern is a location path whose steps all use only the child or attribute axes. Although patterns must not use the descendant-or-self axis, patterns may use the // operator as well as the / operator. Location path patterns can also start with an id or key function call with a literal argument. Predicates in a pattern can use arbitrary expressions just like predicates in a location path.

Cheers
Sameer

[Jayadev Pulaparty]

Sameer,
The following is the reason due to which i believe that "*[@*]" refers only to elements.
When we say <xsl:template match="something">, this has absolutely no idea of the context in which the element exists. More specifically, when i say <xsl:template match="*[@*]">, i feel that it tries to match any element that has attributes and not necessarily child elements.
I strongly feel that the default axis being the child axis and all that comes into picture "when we are in a context". My simple question is "child of what" and the answer would be the "context node". I can't give you quotes from some good books supporting my argument. I go by my intuition + practicing the examples to verify my concepts. You can prove me to be wrong and i'll be glad to learn something on every occasion . I'll be looking forward to hear from you and our other ranchers about their take on this question.
One more little thing i forgot. If you look at the way in which the default template mechanism works to traverse the tree, we see that <xsl:template match="/"> will be the first one impacted. It simply says <xsl:apply-templates /> which delegates the processing to all its children. Then our <xsl:template match="*[@*]"> comes into picture and its definitely <xsl:apply-templates /> guy is the one saying that pass on to my child elements. I can give you some examples to substantiate my argument, but i'm a little busy today with my office work.
<QUOTE>
Simply put,
<xsl:template match="someElement">
<xsl:for-each select="*[@*]">
...........
</xsl:template>
in the above example, "*" means "child::*[@*]", but not in the below example -
<xsl:template match="*[@*]">
.......
</xsl:template>
</QUOTE>
Thanks.

[Roseanne Zhang]

My original statement is correct. Proved by the following example. Try, please!
Source XML:

<Root id="r">
  <sub id="a">
    <sub1>
      <sub2 id="b"/>
      <sub2>There is not attr here.</sub2>
    </sub1>
    <sub1 id="c"/>
  </sub>
  <sub>sub content without attr</sub>
</Root>    

XSL:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">  
  <xsl:template match="/">
    <xsl:apply-templates />
  </xsl:template>
  <xsl:template match="*[@*]" >
    <new>
      <xsl:copy-of select="." />
    </new>
  </xsl:template>
</xsl:stylesheet>

Result XML:

<?xml version="1.0" encoding="UTF-8"?>
<new><Root id="r">
  <sub id="a">
    <sub1>
      <sub2 id="b"/>
      <sub2>There is not attr here.</sub2>
    </sub1>
    <sub1 id="c"/>
  </sub>
  <sub>sub content without attr</sub>
</Root></new>

Observations:
a) Only one element <Root> is copied, which is the only child of Document node "/", which matches the template.
b) The <new> element appears only once, which indicates the template for match="*[@*]" being called only once.
c) Those no-attribute elements are in result xml. However, it is not because they match the template, but because they are parts of the <Root>.
Something more interesting
1) I could not override this template for match="*[@*]", by using a new template, which match="Root[@id]".
2) I'm using xalan transformer, but the result is not xalan specific. I also tried IE by using an html output; and I got a similar result.
3) Finally, I figure it out. The two templates both have priority of 0.5. If I make one of them priority="0.51", that one will prevail.
4) Somehow, they both choose match="*[@*]" over match="Root[@id]", even they have the same priority. The spec says they could raise an error.
5) At least, xalan and IE are working in the same consistent way.
6) The part (5.5 Conflict Resolution for Template Rules) of XSLT SPEC is hard to read to me.
It is a real good learning experience to me.
Thanks for the excellent discussion! Without you guys, it is impossible for me to go this far!
[ November 01, 2002: Message edited by: Roseanne Zhang ]

[Jayadev Pulaparty]

Roseanne,
I'm on some medication which makes one drowsy, but your postings are keeping me awake Your example output is no surprise to me. Please tell me one thing -
When we say <xsl:template match="*[@*]">, you say that the child axis is implied there. My feeling is that child axis makes sense only when i'm in a particular context. No egos I'm honestly learning a lot from this discussion of ours.
Thank you personally .

[Scott Duffy]

Originally posted by ZEESHAN AZIZ:
Well, best of luck with your beta exams. Well, I was wondering whether the results of this exam would count towards your mcsd.net cert
...

Microsoft Beta exams:
- are by invitation only
- are free
- count towards the final MCSD .NET certification
- are much longer than the real test will be
For instance, the 70-300 beta for solutions architecutre is scheduled to last 5 HOURS.
I took a beta once before (for 70-100 Solutions Architecture, funny enough) and it was kind of grueling. I went in there with a bottle of water, bottle of Coke, and a sandwich. I knew I was going to be in there a while.
Scott

[Roseanne Zhang]

My above observation of the template priority is partially not correct. See a correct answer here, thanks!
http://bobcat.webappcabaret.net/javachina/faq/xslt_01.htm#xslt_Q20