aspose file tools*
The moose likes Product and Other Certifications and the fly likes JavaRanch XML mock exam errata-2 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Product and Other Certifications
Bookmark "JavaRanch XML mock exam errata-2" Watch "JavaRanch XML mock exam errata-2" New topic
Author

JavaRanch XML mock exam errata-2

Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
Clarice Tang sent me an e-mail with comments about "core XML exam".
We agreed to post our correspondence here, so others can also enjoy it, and maybe add something.
I don�t think Answer c can be a correct answer for Question 14.
Attributes can have NAME of unparsed entity as their values, but unparsed entity REFERENCEs, which take the form of &entityName;

(I already changed question 14, so you may wonder, what they are talking about? Here is the old variant:
As their values attributes can have:
a) general entity references
b) parameter entity references
c) unparsed entity names
d) CDATA sections )
You are right in that attributes can have NAME of unparsed entity as their values, i.e it would be
<myElement myAttribute="myEntity">
not
<myElement myAttribute="&myEntity;">
But the term "reference" is used in both cases. For example, This is from Simon St. Laurent�s "XML elements of style": "All that remains is to declare the unparsed entity � probably in the internal DTD subset of the document that uses it � and REFERENCE it in an element."
or
"attributes of the ENTITY or ENTITIES types are used to allow a reference to an unparsed external entity to appear within a document."
So it is a reference in both cases. In case of a parsed entity if takes a special form of &entityName; and an unparsed entity is referred to simply by name.
But I agree that "As their values attributes can have unparsed entity names" is less confusing, so I changed this question.
From the following E-mal:
Your exam makes me reading the EBNF of xml specs very carelly. Reference ::= EntityRef | CharRef
EntityRef ::= '&' Name ';'
So I think Entity references always take the form of '&Name;'.

I think I can see where confusion came from. Mapraputa, like the authors quoted above, used the term "reference" or "to refer to" in non-strict sense, belonging to natural language, English in this particular case. You quote XML specification written in a very formal language � EBNF. Here meaning of the word �reference� is strictly defined and is more restrictive than in casual language. As a result, we have a clash.
Here is what an intermediate level of formality, XML specification, says:
"Parsed entities are invoked by name using entity references; unparsed entities by name, given in the value of ENTITY or ENTITIES attributes."
So "unparsed entity names" is indeed more precise term.
Answer b of Question 21 couldn�t be a correct answer. It should be changed to has external parameter entity references , I think. Because when standalone= yes , referring to external general entities is ok.
That�s a good point! First, the question itself should be better worded.
"Attribute standalone="no" must be included in XML declaration if a document..." Here "should" would be better than "must", because there is no absolute "must", there can be situations when an application doesn�t need to validate an XML document, and, therefore, may choose to ignore an external DTD.
As for external general entities, you are right. I based this option on a rather vague phrase from "Beginning XML": "yes specifies that this document exists entirely on its own, without depending on any other files" which is too general. XML specification says "Note that the standalone document declaration only denotes the presence of external declarations; the presence, in a document, of references to external entities, when those entities are internally declared, does not change its standalone status."
Non-validating parsers are not required to support external general entities, and standalone declaration will not change this behavior. As for external parameter entity references, I was going to change option b to it, but then it occurred to me that "has an external DTD" option includes DTD referenced by external parameter entity. So I simply set option B to �wrong�.
Thank you, Clarice, for bringing out these points!

Uncontrolled vocabularies
"I try my best to make *all* my posts nice, even when I feel upset" -- Philippe Maquet
manj ananda
Greenhorn

Joined: Jun 14, 2001
Posts: 16
I found another confusion with the mock [Test 3], I've send a mail to the author.
Here is,
[DTD by Sanjay. NO.3]
Which of the following code is valid?
a)<!DOCTYPE test [ <!ELEMENT test (#PCDATA)>]>
b)<!DOCTYPE test [ <!ELEMENT test.dtd (elm1|elm2|#PCDATA) >]>
c)<!DOCTYPE test [ <!ELEMENT test.dtd (#PCDATA|elm1|elm2) >]>
d)<!DOCTYPE test [ <!ELEMENT test test (#PCDATA)>]>
e)<!DOCTYPE test [ <!ELEMENT test "test" (#PCDATA)>]>
It answers a & c
but i doubt with c,
to my knowledge i think it should be,
c)<!DOCTYPE test [ <!ELEMENT test.dtd (#PCDATA|elm1|elm2)* >]>
(Note the *)
Am i right Map?
KrisVS


[This message has been edited by manj ananda (edited June 15, 2001).]


SCJP2, IBM XMLC, SCWCD
Mapraputa Is
Leverager of our synergies
Sheriff

Joined: Aug 26, 2000
Posts: 10065
<!DOCTYPE test [ <!ELEMENT test.dtd (#PCDATA|elm1|elm2)* >]>
is correct and I am not sure about asterisk-lacking version... So I changed question 3 to the last, obviously correct variant, until somebody proves that the previous one was correct also
Ashik Uzzaman
Ranch Hand

Joined: Jul 05, 2001
Posts: 2370

I liked the link bartender....specially for a newcomer in XML like me....

------------------
Muhammad Ashikuzzaman (Fahim)
Sun Certified Programmer for the Java� 2 Platform
--When you learn something, learn it by heart!


Ashik Uzzaman
Senior Member of Technical Staff, Salesforce.com, San Francisco, CA, USA.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JavaRanch XML mock exam errata-2