Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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?
|
