[Mono-bugs] [Bug 36704][Nor] Changed - Assorted System.Xml.XmlSchema fixes
Tue, 18 Feb 2003 13:15:06 -0500 (EST)
Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.
Changed by email@example.com.
--- shadow/36704 Mon Feb 17 18:39:54 2003
+++ shadow/36704.tmp.2231 Tue Feb 18 13:15:06 2003
@@ -1,12 +1,12 @@
Product: Mono/Class Libraries
@@ -73,6 +73,63 @@
Created an attachment (id=3132)
Read multiple XmlNode's in an <appinfo> element; expect the correct closing tag on <appinfo> and <documentation> elements.
------- Additional Comments From firstname.lastname@example.org 2003-02-17 18:39 -------
I'll ask Atsushi to take a look at this.
+------- Additional Comments From email@example.com 2003-02-18 13:15 -------
+Hi Peter, thanks and sorry to be so late.
+In fact I'm not schema guy and maybe incompletely understanding.
+> - add actual handling of the XmlSchema.isCompiled member variable:
+> in all routines that change the schema's textual description and
+> to true upon a successful run of the XmlSchema.Compile() method.
+Hmm... isn't it hard work to check *all* the members (including all
+subcomponents)? It will make schema classes so complicated.
+One easier solution I thought is (1)to keep schema string using Write
+() method, and (2)when going to Compile(), create current schema
+string as same way, compare with kept schema string, and if they are
+different, then continue Compile() process.
+> - XmlSchemaAppInfo.cs: add the ability to read more than one
+Doesn't your code handle all descendants as if they were children?
+> - XmlSchemaAnnotation.cs: note that XmlSchemaAppInfo.Read() and
+> XmlSchemaDocumentation.Read() return with the reader positioned at
+> the respective element's end, *not* at the next element or at
+> the annotation end. Thus, expect and swallow an EndElement for
+> 'appinfo' or 'documentation', instead of choking while expecting
+> an EndElement for 'annotation'.
+Sure, you are right.
+> - XmlDocument.ReadNode: check if the reader is already positioned at
+> an Element, and if so, do not do a Read() that will skip the start
+> tag of the element.
+If your patch is applied, ReadNode() will arise infinite loop. BTW,
+what XmlReader did you used at that time? I assume that XmlNodeReader
+had such bug that didn't handle starting node correctly, and maybe
+fixed in current cvs.
+I'll be grateful if you have some tests for those schema problems.
+Anyway, I've fixed XmlSchemaObjectEnumerator and XmlSchemaAnnotation.
+Thanks again for those checks and patches!
+ Atsushi Eno