Hey, you are exactly right Henry.  I think I have a brain block when it
comes to the use of anonymous groups (what I call the part in parenthesis
(form,other*)?).  Never thought to use one.

Remind me to tell you some day about how we invented our own path syntax to
access these specific types elements of a document using the DTD as a road
map.  And XSLT/XPath have NOTHING to do with it I can assure you...

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2001 12:59 PM
To: [EMAIL PROTECTED]
Subject: RE: Need help with DTD




Hello,

     I agree with what Bill Mason says about the model being
non-deterministic.  Although Xerces-J appears to handle it correctly, it's
best not to write it in this form.

   <!ELEMENT page (other*,form?,other*)>

However, I believe the following is equivalent and is deterministic.

   <!ELEMENT page (other*,(form,other*)?)>

Thanks,

Henry
------------------------------------------------------------------------
Henry Zongaro      XML Parsers development
IBM SWS Toronto Lab   Tie Line 778-6044;  Phone (416) 448-6044
mailto:[EMAIL PROTECTED]


Bil Mason <[EMAIL PROTECTED]> on 2001/04/03 10:59:45 AM

Please respond to [EMAIL PROTECTED]

To:   [EMAIL PROTECTED]
cc:
Subject:  RE: Need help with DTD


<!ELEMENT page (other*|form|other*)>

will ONLY validate examples 3 & 4.

<!ELEMENT page (other*,form,other*)>

is what you probably meant but it will NOT validate examples 2 and 3
(no required form elements). By the way,

<!ELEMENT page (other*|form?|other*)>

will not work either but

<!ELEMENT page (other*,form?,other*)>

will.  I'm sure that's what E. de Haan meant in the first place.


At any rate, the modified E. model is definitely non-deterministic.
Given an initial other element (or series of other elements), it is
not possible for the parser to determine which one(s) you are
referring to without looking to see if a form element exists.

It gets REALLY interesting when you start listing all of the
possible ways you could interpret this document:

<page>
           <other>A</other>
           <other>Z</other>
</page>

For example:

1) the first other element (A) and the second other element (Z) are part
of a single group represented by the first other* in the first definition
of page.

2) A is a member of the first other* and Z is a member of the second
other*.

3) A and Z are both members of the second other*.


Sadly, this is just the nature of XML DTDs.  This is the only way to
represent the content model in question but according to the spec., it is
the wrong way!

However, if you read the spec. closely, you will notice that although "it
is required that content models in element type declarations be
deterministic" (Extensible Markup Language (XML) 1.0 (Second Edition),
Appendix E), it is NOT required that a parser report non-deterministic
models as an error.

Could it be that someone from the original design group actually realized
that DTDs were NOT going to be able to represent this scenario?  Perhaps
by "ignoring" the problem, they could allow parser writers to pick up the
slack?

NOTE: Xerces-J handles <!ELEMENT page (other*,form?,other*)> just fine.



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





======================= Confidentiality Statement ======================= 
The information contained in this message and any attachments is 
intended only for the use of the individual or entity to which it is 
addressed, and may contain information that is PRIVILEGED, CONFIDENTIAL 
and exempt from disclosure under applicable law.  If you have received 
this message in error, you are prohibited from copying, distributing, or 
using the information.  Please contact the sender immediately by return 
e-mail and delete the original message from your system. 
===================== End Confidentiality Statement =====================  



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to