Not sure if this helps or not, but here's what we're doing
for
SwitchYard.
1. We're using catalog.xml files for all SwitchYard related schema.
2. The target URLs are relative, which makes it easy to specify the
target schema (i.e. you don't have to use something like:
platform:/plugin/path/to/schema.xsd).
3. Catalogs are chained, which makes it easy to group the types of
schema, e.g. third-party, 1.0, 1.1, 2.0, etc.
4. You don't need to figure out how the XML tools extension points
work.
5. The catalog files are portable, e.g. I can manually add the base
catalog from my tools project to my development workspace get schema
resolution working (obviously, I need to make sure my tools project is
up to date, but it works most of the time).
Excellent - I was wondering about using the catalog format but couldn't
find an example. Yours definitely helps and much better agreed.
I talked with Rob S. on chat today and the biggest problem we got is a
bunch of the schemas we got does not really have a clear
definition/documentation
on were they came from...so that needs to be cleaned up/figured out
first.
And yes - the catalog approach is definitely a simpler setup.
Thanks!
Feel free to ping me on IRC.
Here's the project link (note, the schema folder is populated via
maven dependency unpack):
https://github.com/jboss-switchyard/tools/tree/master/eclipse/plugins/org...
Here's the resulting plugin jar (might be easier to look at):
http://download.jboss.org/jbosstools/updates/stable/kepler/integration-st...
----- Original Message -----
> hey,
>
> I started by reading the docs for catalogcontributions.
>
http://www.eclipse.org/webtools/wst/components/xml/M5/new_and_noteworthy/...
>
> This doc describes that 'public' is what is used to "associates a URI
> reference with the public identitier portion of an external
> identifier"
> and uri "uri element associates a URI reference with the a URI
> reference
> that is not part of an external identifier."
>
> Thus these are two different things.
>
> You need a at least a public entry to make it work for when users
> don't
> list identifiers and uri is for when direct urls are used.
>
> Thus if you don't have public entries then it explains why it does
> not
> work.
>
> Other background info:
>
http://www.eclipse.org/webtools/wst/components/xml/M5/new_and_noteworthy/...
>
http://wiki.eclipse.org/Using_the_XML_Catalog
>
>
>> I'm looking at separating out the xml schema catalog entries into
>> their
>> own plugin, and a request has been made to add even more schemas.
>
> btw. if you are going to create new plugin please name the dir
> "schemas"
> not just dtd ;)
>
>> But
>> I'm having a problem discovering how to do it uniformly. There are
>> several syntaxes used to add entries, and I really don't know which
>> syntax to use and when:
>
> See above - public != uri.
>
>> We use the following syntaxes at varying times:
>>
>> This first one (FORMAT 1) is most often used by our legacy dtd's,
>> and
>> I
>> honestly have no idea how it works at all:
>>
>> <public publicId="-//JBoss//DTD JBOSS 4.0//EN"
>> uri="platform:/plugin/org.jboss.tools.as.catalog/dtd/jboss_4_0.dtd"
>>
webURL="http://www.jboss.org/j2ee/dtd/jboss_4_0.dtd"/>
>
> This is the entry that defines if you have a public id "-//JBoss//DTD
> JBOSS 4.0//EN"
> eclipse should look at this uri inside your plugin to get the schema.
>
>> I've seen this next entry (FORMAT 2) added as well. The thing to
>> note
>> here is that the name attribute, which I believe represents
>> namespace,
>> is set to
http://www.jboss.com/xml/ns/javaee, but an open jira
>> indicates
>> this type of catalog entry will form invalid xml files and we should
>> avoid it.
>>
>> <uri
name="http://www.jboss.com/xml/ns/javaee"
>>
uri="platform:/plugin/org.jboss.tools.as.catalog/dtd/jbossws-web-services_1_0.xsd"/>
>
> Which jira ?
> What actually happens ?
>
>> The next syntax (FORMAT 3) is similar, but seems to have a namespace
>> that points to a specific xsd file.
>>
>> <uri
name="http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
>>
uri="platform:/plugin/org.jboss.tools.as.catalog/dtd/jboss_5_0.xsd"/>
>
> I don't think there are any difference between FORMAT 2 and FORMAT 3
> -
> they are just mappings of two uri's.
>
>> The fourth (FORMAT 4) seems most often used by our newest schema,
>> and
>> seems the most successful one.
>>
>> <uri name="urn:jboss:1.0"
>>
uri="platform:/plugin/org.jboss.tools.as.catalog/dtd/jboss_1_0.xsd"/>
>
> Define succesful ?
>
> This is simply mapping that when you use urn:jboss:1.0 as a namespace
> uri it will use this specific resource to locate it.
>
> Thus in short - you got *2* different entries, public and uri. They
> do
> different things (hence different names).
> and inside uri you are simply mapping a "virtual name" to a specific
> different resource that the tool can use.
>
>> The problem for me is that when I look at many other xsd files that
>> could be added, they don't show namespaces in a urn:jboss format.
>
> No, that is extra knowledge but they follow the same pattern so could
> probably be automated.
> Just need to verify against actual documentation on how to use these
> JBoss dtd/xmls.
>
>> Looking at the xsd files directly, they also don't have a string
>> like
>> "http://www.jboss.org/j2ee/schema/jboss_5_0.xsd" anywhere in the xsd
>> file, so I can't use formats 4 or 3. I have no idea how format 1
>> works,
>> and format 2 has been indicated to be non-functional.
>
>> So if I want to add an xsd file that has header like the one below,
>> I
>> have no idea how to add it:
>>
>>
>> <xsd:schema
>>
targetNamespace="http://java.sun.com/xml/ns/javaee"
>>
xmlns:javaee="http://java.sun.com/xml/ns/javaee"
>>
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>> elementFormDefault="qualified"
>> attributeFormDefault="unqualified"
>> version="2.1">
>
> I don't actually think xmlcatalog will even affect this creation -
> can
> you give me an example on how ?
>
> /max
>
http://about.me/maxandersen
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>