wst/components/xml/M3/milestone_plan.xml

<?xml-stylesheet type="text/xsl" href="../../../../development/milestone_plans/stylesheets/milestone-bulletList.xsl"?>

<plan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:noNamespaceSchemaLocation="../../../../development/milestone_plans/milestonePlan.xsd">
	<component name="xml" subproject="wst">
		<description>
			Milestone planning for XML Core, UI, and Tools
		</description>
		<milestone name="M3">
			<title>
				M3 Plan Status: under development and
				review - updated 2005-2-22
			</title>
			<category name="Design for Platform Use">
				<item priority="high" status="in-progress">
					<description>
						Document Designs, API, JUnit tests, and Performance Tests
					</description>
					<detail>
						During M3 we'll focus primarily on core (model)
						Designs and APIs. We'll detail not only
						"standard" DOM APIs we support, but also, the
						extensions to that API, related to Adapters and
						ReadOnly APIs.
					</detail>
				</item>
				<item priority="medium" status="in-progress">
					<description>
						continue refactoring to improve separation of
						components
					</description>
				</item>
			</category>
			<category name="Misc. Items">
				<item priority="low" status="deferred">
					<description>
						implement (minimal) DOM Core 3
					</description>
					<detail>
						Some intend to use our code with JDK 1.5. While
						we don't claim to support full compliance with
						1.5 (or with DOM Core 3 APIs), this is an area
						than may cause -verify errors even if 1.5 runs a
						1.4 library.
					</detail>
				</item>
				<item priority="low" status="deferred">
					<description>
						Investigate: add (non-standard) DOMOperation
						API.
						<detail>
							Its purpose is to optimize notifications,
							undo "units", and also handle such things as
							auto-pre-formatting for all clients.
						</detail>
					</description>
				</item>
			</category>
		</milestone>
		<milestone name="M4">
			<title>
				M4 Plan (initial Rough Draft - last updated 2005-1-11 -
				to be completed at end of M3)
			</title>
			<category name="Design for Platform Use">
				<item priority="high">
					<description>Graphical Table View</description>
				</item>
				<item priority="high" status="in-progress">
					<description>
						Finish Document Designs, API, and JUnit tests
					</description>
				</item>
				<item priority="medium" status="in-progress">
					<description>
						Finish refactoring to improve separation of
						components
					</description>
				</item>
			</category>
			<category name="Eclipse base parity">
				<item priority="medium" status="in-progress">
					<description>
						Investigate Unified Validation marker/annotation
						model.
					</description>
					<detail>
						Currently, the "as you type" validation and
						"batch" validation can give different results,
						since they have different quality of location
						information. Craig has an idea on how to
						implement our own XNI validator, using
						StructuredDocuments, to improve quality of
						location information (though, need to test
						performance impacts, etc.). From users point of
						view, will be nicer since an existing red-X in
						vertical ruler can then "turn grey" once user
						fixes suspected problem, and then when file
						saved, will either disappear (if truly fixed) or
						turn red again, if not fixed.
					</detail>
				</item>
			</category>
		</milestone>


	</component>
</plan>