Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Question about XML Catalog Contributions

<shrug>

This is one of those Java vs C++ debates and I doubt that there will ever be
a singular agreement on this topic. I think it would be fair to say that the
original intention for the schema location hint has nothing to do with how
it is actually used today. :)

>From what I've seen, the use of schema location is very widespread and many
schema publishers practically require it by not serving schema from
namespace URI. While it's conceivable that a schema processor would choose
to ignore the schema location hint, other solutions to this problem have
larger issues. Take the custom resolver approach as an example. That is
guaranteed to have one behavior in Eclipse and another behavior in every
other xml processor.

- Konstantin


-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of David Carver
Sent: Friday, October 02, 2009 2:55 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Question about XML Catalog Contributions

 From an XML standpoint, SchemaLocation itself, is a bad practice in 
general.  No guarantee that it is going to be honored, as according to 
the spec it is just a Hint, and implementations can ignore it and over 
ride it.   From an XML stand point, custom resolvers are a better way to 
handle this, and using the namespace.

Schemalocation can cause so many interop issues, that most standard orgs 
don't recommend their use.

Dave


Konstantin Komissarchik wrote:
> Another way to solve this is to not use namespace uri as schema location.
> That way right in the descriptor, you can map the same namespace URI to
> different schema locations that hold schemas at different version levels.
> The nice thing about this approach is that it is transparent to the user.
> They can look at the file to see exactly where the schema is coming from.
If
> there is any ambiguity, they have a URL to paste into the browser to pull
up
> exactly the version that is referenced. This also provides relatively
> straightforward version transitions. Just change the schema location
> mapping.
>
> To integrate this with XML Catalog, you map the schema location URL to the
> plugin resource instead of the namespace URI.
>
> In tooling, there is typically a version that's implicit in the context.
> Maybe something like the facet version. You can validate context version
> against the expected schema location URI to make sure they match and flag
a
> problem if they don't (with quick fixes if you want to be fancy).
>
> This is the approach that we took in Oracle's Eclipse tooling when dealing
> with WebLogic Server descriptor schemas.
>
> - Konstantin
>
>
> -----Original Message-----
> From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Jesper Steen Møller
> Sent: Friday, October 02, 2009 2:26 PM
> To: General discussion of project-wide or architectural issues.
> Subject: Re: [wtp-dev] Question about XML Catalog Contributions
>
> We had this problem in XSL Tools, and ended up writing a specialized
> resolver for it which peeked the version and returned the correct
> schema. Having to write a resolver for each such schema doesn't scale
> well in the general case, and is hidden from the user (i.e. doesn't
> show up in the catalog), but it gets the job done.
>
> I forget if the XML Catalog spec welcomes extensibility, but since
> processors such as Xerces resolve schema locations by looking at 'uri'
> entries in the catalog, it would make sense to add it there, using
> e.g. xpath:
>
>   <uri name="http://java.sun.com/xml/ns/persistence/orm";
>       uri="file:///some/path/persistence-orm-1.0.xsd">
>   <uri name="http://java.sun.com/xml/ns/persistence/orm";
>       uri="file:///some/path/persistence-orm-2.0.xsd"
>       catx:version="2.0"/>
>
> using the catx:version attribute as a tie-breaker when matching
> catalog entries (this assumed that the version is an attribute on the
> root element). Or, even more general:
>
>   <uri xmlns:orm="http://java.sun.com/xml/ns/persistence/orm";
>       name="http://java.sun.com/xml/ns/persistence/orm";
>       uri="file:///some/path/persistence-orm-2.0.xsd"
>       catx:test="//orm:entity-mappings/@version = '2.0'"/>
>
> I guess this could be prototyped into the Eclipse Catalog support to
> see if it is viable.
>
> However, the standards compliant way is to use XML Schema 1.1 which
> supports conditional type assignment, so it will be possible to have a
> schema for entity-mappings which has a dynamically determined type for
> any given particle.  But this requires involvement of the schema
> author, and commitment to XML Schema 1.1.
>
>
> -Jesper
> On Fri, Oct 2, 2009 at 10:45 PM, Paul Fullbright
> <paul.fullbright@xxxxxxxxxx> wrote:
>   
>> Does anyone know if there is a way to take document version into
>>     
> consideration when registering a schema for a namespace?
>   
>> Java Persistence uses the same namespace for all versions of their
>>     
> documents, and so it seems only possible to register the latest version of
> the schema for validation for that namespace, and documents such as:
>   
>> <?xml version="1.0" encoding="UTF-8"?>
>> <entity-mappings version="1.0"
>>   xmlns="http://java.sun.com/xml/ns/persistence/orm";
>>   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>> </entity-mappings>
>>
>> show up as invalid since the version does not match the fixed value of
>>     
> "2.0" required by the latest version of the schema.  (Also, any new
elements
> or attributes for 2.0 would show up as valid, even if not valid for 1.0.)
>   
>> --
>> Paul Fullbright
>> Eclipse Java Persistence Tools (Dali) Development
>> Oracle
>>
>> _______________________________________________
>> wtp-dev mailing list
>> wtp-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>>     
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
>   

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev



Back to the top