• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Liutauras Vilda
  • Henry Wong
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Al Hobbs
  • Carey Brown
  • Piet Souris
  • Mikalai Zaikin
  • Himai Minh

JavaRanch XML mock exam errata-2

Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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">
<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."
"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!
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?

[This message has been edited by manj ananda (edited June 15, 2001).]
Mapraputa Is
Leverager of our synergies
Posts: 10065
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<!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
Ranch Hand
Posts: 2378
MySQL Database Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic