Certainly the patch suggested seems risk-free from an interoperability and
technology perspective.
Perhaps it doesn't offer as many benefits as suggested but that's not the
point here. (any risk-free benefit is good right?)
I think the only known parser to have this problem is Xerces (and hence all
the tools and applications that use Xerces).
I'm not sure why people feel that a full check for schema grammar must be ON
while validating GML 2.x instance documents. It's an accepted canonical XML
information model (with known minor bugs). Why validate the model unless
you're developing or modifying the model (or extensions thereof)?
An example of when you would want to have schema grammar checking on is when
developing a Profile that extends/uses GML types. Then you would want unique
particle attribution constraint checking and particle derivation restriction
checking
(which is what the
http://apache.org/xml/features/validation/schema-full-checking parser feature
does).
A quick note about that feature:
"This feature checks the Schema grammar itself for additional errors that are
time-consuming or memory intensive. It does not affect the level of checking
performed on document instances that use Schema grammars."
I think some users are confused by the difference between validation of the
instance document (e.g. WFS request/response documents) and validation of the
schema itself (e.g. GML's geometry.xsd or Rob's Gazetteer profile schema etc)
I guess from a Geoserver perspective you still want users to be able to use
extensions of GML 2.x and have full-schema-checking if they so desire. But
given the performance implication and the redundancy of the operation after
an initial check it seems an undesirable thing to do at runtime.
Regards,
Nick Ardlie
Geoscience Australia
GPO Box 378
Canberra ACT 2601
(02) 6249 9886
http://www.ga.gov.au
nicholas.ardlie@anonymised.com
-----Original Message-----
From: geoserver-devel-bounces@lists.sourceforge.net
[mailto:geoserver-devel-bounces@lists.sourceforge.net] On Behalf Of
rob@anonymised.com
Sent: Thursday, 7 December 2006 9:56 AM
To: Saul Farber
Cc: geoserver-devel@lists.sourceforge.net
Subject: Re: [Geoserver-devel] [jira] Created: (GEOS-820) GML 2.1.2 schemas
don't validate in Xerces
Patch - no problems. +1
Your reasoning as to why its worthwhile makes sense, but the explicit
assumption I was missing, and I think we both agree on, is that people
will have to validate against a hacked copy of the schemas in practice.
This still requires a fair bit of knowledge how to use the tools
properly, and is again why GML 3.1.1 must be taken forward.
Rob
Saul Farber wrote:
Good points Rob.
I think, however, that my original question has gotten a bit derailed.
I'll give it one more shot.Here's my summary of the emails so far:
1) GML 2.1.2 schemas have a bug in them. This bug causes xerces and
XMLSpy (and possibly other parsers) to not properly validate any
documents referencing geometry.xsd2) GML 3.1.x does not have such a bug. The future (including WFS 1.1)
has lots of GML 3.1.x in it.3) There exists a very simple fix to the GML 2.1.2 schema bug which
will allow GML 2.1.2-based documents (all WFS 1.0/SLD 1.0 requests) to
validate and gain the advantages of validating. Schema<->language
binding tools, eclipse auto-complete, general sanity checks, etc.4) Chris is in the process of pushing OGC to "quickly" (1-2 months?)
apply the fix from #3 to GML 2.1.2 via a corrigendum.My question is:
Is there any reason that Geoserver should *not* apply the gml-2.1.2-fix
to geometry.xsd?The patch will not invalidate any existing XML documents, and will not
make any documents which are currently invalid valid. The patch does
*not* change the content-model of geometry.xsd in any way.The patch *will* let people hit "validate" in their favorite XML editor
without errors. It will let eclipse perform auto-completion for SLD,
WFS and GML when using an XML editor with schema-awareness (WST, oXygen,
etc.). It will let folks using xerces-based GML <-> language binding
tools use these tools more effectively.In addition, there's no effort "burnt" on this (other than my time
writing long-winded emails!) The patch exists, it works, application is
approximately 30 seconds, most of which is waiting for the ssh login
prompt to appear.Anyone have a reason not to apply this fix?
--saul
Rob Atkinson wrote:
A known problem.
There is a logical answer of course:
GML 2.x is deprecated.
move to GML 3.1.1 and WFS 1.1 ASAP instead of burning effort on this.
On the more general side, schema validation is problematic at run time
due to performance reasons. A few salient points:1) GML does not rely on the PSVI being richer.
2) Validation on insertion makes more sense, but you generaly need
something much stronger than schema validation to ensure the content
meets the typical foreign-key constraints we are used to in DB-land
3) OASIS Catalogs can be used to find local (cached/hacked/simplified)
copies of schemas - in practice this is the only workable way of using
GML IMHORob
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel