</ul>
-** Plans
-
-*** System.Xml v2.0
+** System.Xml v2.0
Microsoft released the first public beta version of .NET Framework 2.0,
available from <a href="http://www.microsoft.com/downloads/details.aspx?familyid=916EC067-8BDC-4737-9430-6CEC9667655C&displaylang=en">MSDN</a>.
There are two assemblies related to System.Xml v2.0; System.Xml.dll and
System.Data.SqlXml.dll. Most of the important part are in System.Xml.dll
- (you will find that the core part of XQuery is in System.Xml.dll; see some
- classes in MS.Internal.Xml namespace), so I'll still spot only on
- System.Xml.dll.
+ (you will find that the core part of XQuery is in System.Xml.dll; For
+ example, see some classes in MS.Internal.Xml namespace), so I'll still
+ spot only on System.Xml.dll.
- Note that .NET Framework is pre-release version so that they are subject
- to change.
+ Note that .NET Framework is pre-release version, so they are subject
+ to change. Actually many of the pre-released classes vanished.
System.Xml 2.0 contains several features such as:
internal use
</ul>
-**** XmlReader.Create() and ReadValueAsXxx()
+*** System.Xml 2.0
+
+**** XmlReader/XmlWrier Factory methods
In .NET 2.0, XmlTextReader, XmlNodeReader, XmlValidatingReader are
obsolete and XmlReader.Create() is recommended (there is however no
- alternative way to create XmlNodeReader).
+ alternative way to create XmlNodeReader). Similarly, there are
+ XmlWriter.Create() overloads.
+
+ Currently, Microsoft's XmlWriter.Create() is unreliable and maybe there
+ will be changes. So basically XmlWriter.Create() is supposed to be done
+ after the next beta version of .NET 2.0.
+
+ Some of XmlReader.Create() overloads are implemented, with limited
+ XmlReaderSettings support.
+
+
+**** Typed XmlReader/XmlWriter
- As for typed XmlReader support, we need something like XQueryConvert that
- is like XmlConvert but based on XQuery 1.0 and XPath 2.0 data model.
+ In .NET 2.0, XmlReader is supposed to support strongly-typed data reading.
+ They are based on W3C "XML Schema Datatypes" Recommendation and "XQuery 1.0
+ and XPath 2.0 Data Model" Working Draft.
-**** XML Schema design changes
+ Some of XmlReader.ReadValueAsXxx() and XmlWriter.WriteValue() overloads are
+ implemented, though incompletely. They are based on internal XQueryConvert.
+
+
+**** Sub-tree handling in XmlReader/XmlWriter/XPathNavigator
+
+ Currently XmlReader.ReadSubtree(), XmlWriter.WriteSubtree() and
+ XPathNavigator.ReadSubtree() are implemented, though not so stable.
+ They are based on Mono.Xml.SubtreeXmlReader and
+ Mono.Xml.XPath.XPathNavigatorReader classes.
+
+
+*** System.Xml.Schema 2.0
Since .NET 1.x is not so compliant with W3C XML Schema specification,
Microsoft had to redesign System.Xml.Schema classes. We also have to
- change some.
+ change many things.
+
+ 1) It does not expose XmlSchemaDatatype (except for obsolete members).
+ Primitive types are represented as XmlSchemaSimpleType instances (thus
+ there are ElementSchemaType, AttributeSchemaType, BaseXmlSchemaType that
+ replace some existing properties).
+
+ 2) "XQuery 1.0 and XPath 2.0 Data Model" datatypes (such as
+ xdt:dayTimeDuration) are newly supported. They are partially implemented
+ yet.
+
+ 3) schema structures are now bound in parent-child relationship. It is
+ not yet implemented. With related to it, there seems bunch of schema
+ compilation bugfixes.
+
+ 4) XmlSchemaCollection is not used anymore to represent effective set of
+ schemas. Instead, new XmlSchemaSet class is used. It should affect on
+ schema compilation design. In fact, I've implemented XmlSchemaCollection
+ as more conformant to W3C specification, but there are still many changes
+ required.
+
**** XSD Inference
- In .NET 2.0, there is an XML Schema inference implementation. Once
- XmlSchemaSet is implemented, it can be separately done by anyone.
+ In .NET 2.0, there is an XML Schema inference implementation. Now that
+ XmlSchemaSet is basically implemented, it can be separately done by anyone.
Volunteer efforts are welcome here.
-**** New XPathNavigator
- System.Xml v2.0 implementation will be started from new XPathNavigator
- implementation. First, its document structure and basic navigation feature
- will be implemented. And next, XPath2 engine should be implemented
- (XPathNavigator2 looks very different from XPathNavigator).
+*** System.Xml.XPath 2.0
+
+**** Editable XPathDocument
+
+ in .NET 2.0 XPathDocument is supposed to be editable. Currently we provide
+ fast document table model based implementation (DTMXPathNavigator), but
+ by that design change, we (and they) cannot provide fast read only
+ XPathNavigator from XPathDocument anymore.
- My current plan is to implement editable interface for XmlDocumentNavigator
- (XPathNavigator from XmlDocument). Our XPathDocument is index-based
- implementation, and thus it cannot be modified to be editable as it is.
+ Currently, new XPathDocument implementation is provided. The actual
+ implementation is Mono.Xml.XPath.XPathDocument2, that is simple dom-like
+ tree model. XPathDocument2 implements the same interfaces as XPathDocument
+ does. And XPathDocument delegates most of the methods to that class (for
+ example, XPathDocument.CreateEditor() calls XPathDocument2.CreateEditor()).
- There are some trivial tasks such as schema validation (we have
- <a href="http://www24.brinkster.com/ginga/XPathDocumentReader.cs.txt">
- XPathDocumentReader</a> that just wraps XPathNavigator, and our
- XmlValidatingReader can accept any XmlReader).
+ Currently Mono.Xml.XPath.XPathDocument2 is unstable (it does not pass
+ the standalone XSLT tests as well as existing DTMXPathDocument does). So
+ it did not replace existing XPathDocument implementation, but you can use
+ new implementation by explicitly setting environment value
+ USE_XPATH_DOCUMENT_2 = yes. Currently it supports (well, is supposed
+ to support) basic editor feature such as AppendChild(). Other members
+ are untested (such as RejectChanges()).
-**** XQuery 1.0
+**** extra stuff - XPathEditableDocument
+
+ Currently we provide another IXPathEditable; XPathEditableDocument. That is
+ based on the idea that handles XmlDocument as editor target. It is
+ implemented as Mono.Xml.XPath.XPathEditableDocument. We might provide this
+ class as extra set (might be different mono-specific XML assembly).
+
+
+**** System.Xml.XQuery and System.Xml.Xsl 2.0
XQuery is a new face XML data manipulation language (well, at least new
face in .NET world). It is similar to SQL, but intended to manipulate and to
such as XML Schema based datatypes.
XQuery implementation can be found mainly in System.Xml.Query and
- MS.Internal.Xml.Query namespaces. <del>Note that they are in
- System.Data.SqlXml.dll</del><ins> The implementation is mostly
- in System.Xml.dll</ins>.
+ MS.Internal.Xml.Query namespaces. The implementation is mostly
+ in System.Xml.dll. System.Data.SqlXml.dll just invokes the actual XQuery
+ processor which resides in System.Xml.dll using reflection.
XQuery implementation will be done in these steps:
<ul>
* XQuery syntax parser that parses xquery string to AST
- (abstract syntax tree).
+ (abstract syntax tree). -> done.
- * XQuery AST compiler into runnable query command (not done yet)
+ * XQuery AST compiler into runnable query command
+ (static context)
* XQuery (dynamic context) runtime = XQuery expression evaluator
+ sequence iterator.
* XQuery data model and (mainly) conversion support.
</ul>
-**** Relax NG and DSDL in Mono 1.2
+
+*** Relax NG and DSDL in Mono 1.2
Currently we support only RELAX NG as one part of ISO DSDL effort. There
is existing Schematron implementation (NMatrix Project: <a
it can be used with mono.
We also don't have multi-language based validation, namely Namespace-based
- Validation Dispatch Language (NVDL). To support unwrapping, one special
- XmlReader implementation is required. Note that we had seen RELAX Namespace,
- Modular Namespace (MNS) and Namespace Routing Language (NRL) - that is,
+ Validation Dispatch Language (NVDL). To support unwrapping, one special
+ XmlReader implementation is required (other schema validation support will
+ be done by ReadSubtree()). Note that we had seen RELAX Namespace, Modular
+ Namespace (MNS) and Namespace Routing Language (NRL) - that is,
standardization effort is still ongoing (though NVDL looks mostly the same
as NRL).
* Right now there is no ambiguity detection implementation that
would be useful for RelaxngPattern based xml serialization (if
there is need).
+
+ * Because of lack of ambiguity detection, currently
+ XmlMapping could not be provided. But If anyone is
+ interested in such effort, integration with XmlSerializer
+ would be interesting task.
</ul>
Atsushi Eno <asushi@ximian.com>
- last updated 07/11/2004
+ last updated 08/03/2004
projects / mono.git / commitdiff