Comment 1 Nick Sandonato 2011-03-29 16:24:11 EDT

Created attachment 192131 [details]
patch

Comment 2 Nick Sandonato 2011-03-29 16:26:14 EDT

Nitin reviewed this patch for 3.2.4 and we both felt that it would be a good candidate for raising an API exception for M7.

Comment 3 Nick Sandonato 2011-03-29 16:33:34 EDT

The API change that we're adding is exposing a new interface to be implemented as opposed to implementing the existing internal interface.

Comment 4 Nitin Dahyabhai 2011-03-30 02:57:24 EDT

Nick, looks like the schema in the patch sets the extension point to require an implementor of org.eclipse.wst.xml.core.internal.contentmodel.modelquery.IExternalSchemaLocationProvide, not the public version.

Comment 5 Nick Sandonato 2011-03-30 10:03:54 EDT

Created attachment 192189 [details]
patch

I thought I had made that change. Thanks for the second set of eyes.

Comment 6 David Williams 2011-04-05 10:52:33 EDT

This seems fine to me, I know much requested feature over the years. And as long as "new Interface", shouldn't effect current extenders.

And what else has to change? Is there some "ui" to association the "external schema"? Or am I missing something obvious? Or maybe it's already in the patch, just not mentioned here? But, in any case, I think an important feature.

Comment 7 Tim deBoer 2011-04-05 11:04:29 EDT

+1. I have been trying out this patch, and consider this an extremely important & useful feature. I've tested several different scenarios, and have had no problems with the patch.

The kind of scenario that this is most useful is when there is an xml file that is in a known location or being used for an obvious purpose, but for whatever reason (by mistake, convention, etc.) it does not reference a schema. For example, OSGi blueprint.xml files are in a known location, known content type, and usually have an obvious file name, but often do not reference the blueprint schema. Without this patch, the user misses out on schema validation, content assist, and only gets basic editing support.

With the patch, a component that recognizes the file (e.g. OSGi tools in the example above) can tell XML/SSE what schema should be used, and WTP works seamlessly. Everything works as if you had the schema listed directly in the xml file.

Since the main use-case above is for other tools with specialized knowledge to provide the file->schema mapping, I do not beleive we need any UI.

Comment 8 Nick Sandonato 2011-04-05 16:49:56 EDT

Changes released. Thanks, everyone.

Comment 9 David Williams 2011-04-11 13:08:26 EDT

(In reply to comment #7)

Tim, 

I think you "stepped on" my pmc approval flag  ... no biggie ... but gives me opportunity to respond ... 

> ... but for whatever
> reason (by mistake, convention, etc.) it does not reference a schema. For
> example, OSGi blueprint.xml files are in a known location, known content type,
> and usually have an obvious file name, but often do not reference the 
> blueprint schema. 

I would encourage anyone that knows of a "known case" to be sure to work with those providers to have the schema reference included in the xml file. That's the "xml way". The XML document is supposed to be "self describing" and "self validating" rather that depend on naming conventions and and "well known" locations. I don't know the details behind this particular "known case", but at least wanted to make sure it was known to be a bug at the provider level, at least to some degree. 

Just trying to be helpful.

Comment 10 Tim deBoer 2011-04-12 12:36:14 EDT

Sorry for stepping on the flag - I think it was caused by the bugzilla/firefox issue where refreshing a page doesn't always set the flags correctly.

I beleive I have found a case where it is not a provider level problem and a fixed schema is actually an impediment to the user. However, that's somewhat irrelevant - WTP supports many different schemas for the programming models we support, and our adopters far more. We can't possibly have more than an influence over all the specifications that are covered, let alone the sample applications produced, third-party vendors, users making silly mistakes, etc.

Prior to this change, we simply wouldn't validate these files, wouldn't provide content assist, etc. With this change, we have the (opt-in) ability to continue helping the user with these things, even if we're prompting them to add the schema at the same time.