DOM3 ASModel implementation Re: integrating grammar preparsing with the grammar caching API

[John Utz <ut...@singingfish.com>]

Hello Andy,

tnx for the reply

i've altered the subject because i feel that i have committed a minor
act of list abuse (chiming in on a subject for the purpose of getting
other members to spend time on *my* subject) and dont want to hijack the
grammar discussion archive.

On Sat, 6 Apr 2002, Andy Clark wrote:

> John Utz wrote:
> > Preparsing and caching schemas provides for the possibility of eliminating
> > an *incredible* amount of mindless data entry UI maintenance work, iff you
> > have programmatic access to the 'facts' of the schema.
> 
> This is definitely a related topic but not exactly what we're
> talking about in this thread. At the moment, we're discussing
> how best to populate a grammar cache and have those grammars
> used by validation components in the pipeline.

i know :-). i held off as long as i could stand :-)
 
> The obvious next step (or parallel step) would be to define a
> "good" grammar model. The DOM L3 Abstract Schemas module takes
> a fair stab at providing this model. But that model might not
> be right for everyone and might turn out to be useless for 
> other types of grammars that come into use.

elena had indicated that the plan was to sit tight because W3C was going
to emit a new revision of DOM3. i can imagine that it's going to
change *that* much, but i could be wrong.

> > it does require the creation of a toolkit that maps the particles to the
> > UI ( did i use particles correctly? i mean elements and attributes and
> > types generically ). But it's easy to see that this kind of toolkit would
> > be a new space that would inspire multiple alternative implementations.
> 
> Disregarding what is designed or implemented today, exactly
> what do you need access to?

element and attribute descriptions, constraints and relationships.

> Is it limited to a specific grammar type or do you need generic
> grammar access?

i am currently using XMLSchema and will be doing so for the concievable
future.

> If you could flesh out an API that would work for you, we would have a
> basis on which to build further discussion. (Does the DOM L3 model
> work for you, provided that it were actually fully implemented? Is
> there anything missing in the API?)

my attitude is that DOM L3 is just *peachy* because i have reviewed and
said, 'man, i could get *lightyears* down stream with this, if it actually
worked!'

but it's not a particularly valid opinion because i haven't *coded*
against it yet, because it doesnt work.

a fine chicken and egg problem:
 because it seems to me that no work is being done to implement DOM3
because nobody knows if it's any good. but nobody can figure out if it's
any good because they cant use it because nobody has implemented it yet.

what's a teensy bit frustrating is that i have the cycles *now* to bang
some or all of it out ( and i'll put *personal* cycles in if i have to
because i have pretty grand plans for my current project based on this
interface ) but i need some guidance and i dont think anybody in a
position to provide guidance has any cycles to spare for this. it seems
like i am on the junior side of a 'no silver bullet' situation, if anybody
understands that reference.

the current implementation of ASModel is ASModelImpl and it extends
java.lang.Object. That seems like something temporary to me. shouldnt it
be extending the usual suspects like ElementImpl or CoreDocumentImpl?

if somebody could budget the time for an expository email about how they
think that ASModel ought to be implemented, then i'll go bang something
out.

tnx again for allowing me to participate on this list, i'll try not to
abuse it in the future :-)

johnu
 
> -- 
> Andy Clark * andyc@apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-dev-help@xml.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org