This bug should be entered against Hafnium. I'm not sure we 
have a way of doing this...

Ryan- Please communicate this issue to the dev team for the Hafnium editor.

I think this should probably have a different target 
milestone. It should probably be moved to milestone 3. There 
is not way we can change the Hafnium editor at this point in 
the release cycle. It would be better to do after we release 
Milestone 2.

Hafnium issue

This needs to be placed in the Hafnium folks' court.

Marvin-  There's a XML editor feature in the identity Manager bug db.  Write
this there.

I think this has been fixed will regress

Re-assigning to above mentioned feature.

Created attachment 37236 [details]
XML buddy preferences

We should fix our product to be able to set DTD as part of the validation 
preferences in Eclipse.  Given the fact that no DTD information is specified 
in the source we should allow the user to configure DTD validation based on 
root name. See above attachment.

One more note:  XML buddy actually uses several methods to validate against 
DTD.  We should consider each in our product as well although the preferences 
method would be most valuable to us.  I am listing them here for your 
evaluation.

1. The DTD may be contained in your document, in the internal subset of the 
DOCTYPE declaration in the document. 

2. The DTD may be in another file or network resource pointed to by the 
DOCTYPE declaration in the document. 

3. The DTD may be associated through preferences with the root element name in 
your document. For example, the root element html is associated with the XHTML 
Transitional DTD by default. If the document has no DOCTYPE declaration and 
has html as root, it automatically uses that DTD. 

4. The DTD may be associated with the file through resource properties. 

5. The DTD may be automatically generated based on the contents of the 
document. This can be set up as a preference or as a property of an individual 
document. 

6. Finally, the document may use no DTD at all. This happens when there is no 
DTD in a DOCTYPE declaration and none of the above apply. You can't get code 
assist for a document with no DTD. 
In the last two cases (auto-DTD or no DTD) validation reduces to a well-formed 
check. (This was the most-requested feature in XMLBuddy 0.1.x.)

First of all, are you sure the validation bug is fixed? I'm still experiencing
problems with the latest code.

Second, the XML editor can locate (and thus validate based on) a DTD or
XMLSchema if 
1. the DTD or schema is referenced in the XML document and 
2. the DTD or schema is located either in the same directory as the XML file or
the location of the DTD or schema is specified in the XMLCatalog (in one of our
plug-ins).

The DTD needs to be defined in a DocType and the XML schema needs to be defined
in a namespace declaration.

The WST (Web Standars Tools - sub-project of Web Tools Project
(www.eclipse.org/webtools)) XML editor use a similar approach (XML Catalog - an
OASIS standard).

We do not plan to change this and might in fact use at least parts of the WST
XML editor in future releases (after Designer 1.1)

This is beyond the scope of milestone 4.  Marking for m5.

So I have been able to get the validation to work with our DTD registered and if
I add a DocType to the XML document.

However,  we do not have the DocType on any of the policies and speaking with
Shon Vella he does not want me putting one on any policies.  

We need a way to validate our policies without having to put a DocType in them,
is this possible?

Second can we make it easier for the end User to point at a DTD, rather then
having them register them?  

(In reply to comment #14)

I've recently added functionality for validating a DOM document without having a
DocType (or schema reference).

Basically, you need to create a schema handler:
ISchemaHandler schemaHandler = SchemaHandler.getSchemaHandler(DTDorSchemaPath);

If you want this schema handler to be used by the validation in the source
editor, you need to call:
XMLModel.setXMLHandler 
This method should probably be named setSchemaHandler but I'll let you know if
we change the name. 

Does this satisfy your requiments or do you still need to allow the user to
specify the DTD themselves?

The XML Source editor has a right click menu that you can choose Validate, will
the fixes you've implemented work with it?

The second thing is can the end user point to a DTD to validate against.  There
is no easy way for the end user to do this.

Yes, the fixes will work with Validate. It will work just as if you had the
DocType in the XML document.

I've talked to Steen and he'll look at letting the user specify a schema or DTD
to use in the validation (and code completion) on Monday (July 4th).

Steen has looked at validation and made some general improvements as well as
made it possible to attach a DTD or an XML schema (using the right mouse menu in
the source view).

This should be available in the M5 build.

Build:20050711

Options for attach dtd and validate exist when openign designer project in 
Novell XML editor but they are not enabled when using the source view in 
Nate's multipage policy editor.  They exist but the options are greyed out.  
Is there somthing we have to do to enable these options when the XML editor is 
embedded in another editor.

Steen-  Is there work left for you to do for this?  

Thanks

Bill

I believe Karin is currently working on a fix.

This has been fixed. 

The fix required both changes in the XML editor and in the Policy editor. I
haven't been able to test Nathan's changes until today but everything seems to
be working. I'm not 100% sure whether the new XML editor build has made it into
the Designer builds yet. 

build:20050715

Options are now available and I am able to select dirxmlscript.dtd.  I am 
opening the Validation view then changing source to conflict with dtd.  In 
this case I removed the -object in the action do-find-matching-object, see 
below....  Right clicking and then choosing validate does not do anything.  No 
errors in validation view.  This works fine when the xml editor is not 
embedded in Nate's policy builder.  Is there somthing Nate has to call to get 
this to work when embedded in the policy builder?  We have the new XML editor 
code in our designer build.

<?xml version="1.0" encoding="UTF-8"?><policy>
	<rule>
		<description>Match based on name and placement</description>
		<conditions>
			<and>
				<if-src-dn op="in-subtree">people</if-src-dn>
			</and>
		</conditions>
		<actions>
			<do-find-matching scope="entry">
				<arg-dn>
					<token-text>people\</token-text>
					<token-unmatched-src-dn 
convert="true"/>
				</arg-dn>
			</do-find-matching>
		</actions>
	</rule>
</policy>

Actually, the XML validation view is only used when validating external files,
i.e. files that aren't in the workspace, since errors for these files cannot be
shown in the Problems view.

I've just tested this and the errors show up in the problems view. However, the
Problems view might not be visible. I've changed the validation action so that
the Problems view is made visible when validation occurs.

I've sent a new build to Ryan but I don't know when the changes will be in the
Designer builds.

XML Validation view actually shows the errors when validating now.  Other 
errors are now being displayed in the error log at validation time and when 
double clicking on a problem displayed in the XML Validation view.  Karin, I 
do not know what the problem view is that your refering to in the comment 
above.  There is no problem view in eclipse.  Is this a terminology thing?

I am closing this defect and will write the other issues up against the XML 
editor.

You should see the errors in the Problems view and not the XML Validation view.

The Problems view is the standard Eclipse view for showing compile
errors/warnings, schema errors, etc.

Actually, I just found out that the Problems view isn't available in Designer. 
I've sent a mail to Lee Lowry requesting that the Problems view is made 
available in Designer.

Marking closed/resolved fixed bugs public view.

Marking closed/resolved fixed bugs public view.