[
Lists Home |
Date Index |
Thread Index
]
> Plus, this HTML example should also highlight issues about streaming,
> buffering and incremental processing.
>
Yes, but I think HTML highlights the perfect reason for having both ordered
and unordered elements. So we say the <HTML> node needs to be ordered, but
the <BODY> node shouldn't be. The browser shouldn't care if it receives a
<P> node before or a <BR>, or a <TABLE> in front of a <UL> node. So, in XSDs
I suppose you'd have to describe this like this:
<sequence minOccurs="0" maxOccurs="unbounded">
<element name="P"/ minOccurs="0" maxOccurs="1"/>
<element name="BR"/ minOccurs="0" maxOccurs="1"/>
<element name="TABLE" minOccurs="0" maxOccurs="1"/>
<!-- repeat for the other HTML tags -->
</sequence>
That just seems really backwards to me that when order isn't important, why
should the schema language make it important? Again, I understand that at
times, ordered-elements is very necessary, I just also think there should be
allowances for unordered-elements (and IMHO feel flexible XML should be the
default).
-BKN
P.S. Maybe I misunderstood the XML spec, but I didn't get the impression
that element-order was important to just XML. I thought it was something
that schema languages have introduced?
|
