LISTSERV mailing list manager LISTSERV 15.5

Help for XML-L Archives


XML-L Archives

XML-L Archives


View:

Next Message | Previous Message
Next in Topic | Previous in Topic
Next by Same Author | Previous by Same Author
Chronologically | Most Recent First
Proportional Font | Monospaced Font

Options:

Join or Leave XML-L
Reply | Post New Message
Search Archives


Subject: settling an argument
From: Richard Lander <[log in to unmask]>
Reply-To:General discussion of Extensible Markup Language <[log in to unmask]>
Date:Tue, 7 Mar 2000 14:14:17 -0500
Content-Type:text/plain
Parts/Attachments:
Parts/Attachments

text/plain (119 lines)


 Hello,

A co-worker and I are having an argument. Please help us settle it before we
waste any more time. The following instance is reprentative of the topic of
argument:

<!DOCTYPE A [
<!ELEMENT A (B)>
<!ELEMENT B (B*)>
]>
<A>
<B>
<B></B>
</B>
</A>

I maintain that this document is fine, a bit strange, given no text, but
fine. The recursion (B defined as itself) allows authors to go as deep as
they want (ie. 100 levels of B deep - only 2 here) before they choose to use
the optionality of the occurence indicator, '*', allowing/requiring no
content, to pop back up to A.

A further part of the argument is that the '?' (<!ELEMENT B (B?)>) indicator
also allows this sort of depth of recursion, although it limits the width of
each level. '+' and ' ' (nothing) do not allow this sort of recursion,
because they will never allow any way out of the content model. Authors will
have to continually add B child elements until the end of time, or longer.

SUN and NSGMLS parsers agree with my side of the argument.

My co-worker thinks that I am wrong and that my use of occurence indicators
('*' or '?') to achieve recursion is one of convience and an abuse of XML.
He also makes the case that the following model parses in SUN, but is
clearly illegal:

<!DOCTYPE A [
<!ELEMENT A (B)>
<!ELEMENT B (B*)>
]>
<A>
<B>
<B>
illegal text
</B>
</B>
</A>

It is true that the SUN parser parses this document; NSGMLS does not. I see
this issue as a fault of the SUN parser and as ancilliary to our argument.

He also brings up another case, which I see as even further from our
argument. Both SUN and NSGMLS parse the following document, even though the
root element is a child of the C element, which is clearly illegal:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Z [

<!ELEMENT Z ( A )>
<!ELEMENT A (A*, B)>
<!ELEMENT B ( B*, C* )>
<!ELEMENT C ( Z* )>
]>

<Z>
<A>
<A><B><C></C></B></A>
<B>
<B><C><Z>
<A>
<A><B><C></C></B></A>
<B>
<B><C></C></B>
</B>
</A>
</Z></C></B>
</B>
</A>
</Z>


I think that the latter 2 documents are invalid, but that their problems are
issues of parser design, and  have nothing to do with my recursion issue.
For those of you that are having trouble with <!ELEMENT B (B*)>, the
following is a more practical example:

<!ELEMENT B (A,D,B*)>
<!ELEMENT A (#PCDATA)>
<!ELEMENT D (#PCDATA)>

I use this sort of recursion for SUBSECTIONs in one of my DTDs, since I have
no way of knowing how many levels deep of SUBSECTIONs a given document may
need. My declarations follow:

<!ENTITY % lists        "NLIST|ULIST">
<!ENTITY % body         "(PARA|%lists;|FIGURE|BLOCKQUOTE|QUOTATION)*">
<!ENTITY % block        "(%body;|EXAMPLE|DEFINITION|NOTE|TABLE|table|COLUMNS)*">
<!ENTITY % section
"(TITLE,SUBTITLE?,ABSTRACT?,(PARA|QUOTATION),%block;)">

<!ELEMENT SECTION       (%section;,SUBSECTION*)>
<!ELEMENT SUBSECTION    (%section;,SUBSECTION*)>

Please help us settle this debate, as we are using the same arguments to
convince one another, and getting no-where.

TIA,

Richard


--

Richard Lander
relander at uwaterloo.ca
http://pdbeam.uwaterloo.ca/~rlander/


Professional XML Authoring
http://www.online-learning.com/

Back to: Top of Message | Previous Page | Main XML-L Page

Permalink



LISTSERV.HEANET.IE

CataList Email List Search Powered by the LISTSERV Email List Manager