You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@xerces.apache.org by Ted Leung <tw...@sauria.com> on 2000/01/19 20:00:10 UTC

Re: Proposal for Xerces-J Schema validators for timeInstant and t imeDuration

Curt,

Talk away.  Part of the whole Apache experience is for everybody
to learn from everybody else.   I definitely agree that we not tie the
validator to the DOM.  In fact, the whole issue of exposing type
information to the DOM or SAX or pick your favorite API is kind
of thorny.  You can imagine that someone wants to run  a parser and
get "typed" data out of it, and to do it in the cheapest way possible - with
as little validation as possible or with the assumption that the data is
already
valid.  That would argue for a separate mechanism for making typed data
available.
But in the case where you want to validate and have type aware access to the
data, have 2 distinct mechanisms is a performance problem.  More to think
on.

Ted

----- Original Message -----
From: "Arnold, Curt" <Cu...@hyprotech.com>
To: <xe...@xml.apache.org>
Sent: Wednesday, January 19, 2000 8:17 AM
Subject: RE: Proposal for Xerces-J Schema validators for timeInstant and t
imeDuration


> Dean wrote:
>
> I would be against any tying of the validator to the DOM. This would be
> against the clean layering of the system. Also, you are assuming that DOM
> would be the only place in which such stuff might be stored for later
> validation, which is probably not true. It may just be that either the hit
> must be taken to have the validator revalidate against a lexical
> representation, or some abstraction must be provided via which specialized
> representations can be made available to the validator (which might be a
> big pain, I dunno.) But I just don't think that we would want to get into
> making the validators aware of the DOM itself.
>
>
> Good point.  I was just talking out loud and haven't walked through any of
> Xerces-J.  If that approach was taken, then an interface that would
receive
> the typed data could be defined.  Eventually a type-aware DOM could
> implement that interface.
>