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 * [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
