hi neil;
On Thu, 4 Apr 2002 [EMAIL PROTECTED] wrote:
> Hi Andy,
>
> >>But it seems to me that grammar preparsing is analogous in many ways to
<...massive snippage...>
> Hope to hear from you further Andy; seems like only you and I are following
> these threads these days...
no, not true at all! this is super important to many people.
but my perpective on this issue is so agenda-centric that i felt that i
wouldnt provide any valuable context ( sort of like that 'Far Side'
cartoon about what a dog hears when a human is speaking to it about it's
misbehavior :-) )
but, since i am a pretty involved enduser at this point( i've been
stepping thru the code lots lately), i think it's time to chime in and see
if my selfish perspective can illuminate the discussion. :-)
i have a very specific need. i am not alone in this need. it's come up
from a couple of different parties on the user list, and you can guess
that:
a. other people would have asked if somebody hadnt asked first.
b. a *large* collection of other people will be pretty excited about it
once they see it working and understand why the early requesters
where so excited about it!
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.
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.
for instance, my current project will use an html UI because that's what
the existing system uses already.
> look at all the folks who use our ASBuilder sample, despite
> the idiosyncracies of the interface it's based on! (Nothing wrong with
> being idiosyncratic of course; this conception of grammar
> preparsing/caching is just very different from what we've built in XNI,
> and our implementation of it probably needs to change one day...)
well, for the love of <insert your personal deity here>, what *is* the
right way? None of the accessors in ASModel are implemented! i didnt take
that too hard, i just figured that if i dug deeper, i'd find something
that would let me construct (ok, hack) what i needed.
i have stepped thu my shortened up version of ASModel for 2 weeks now and
i have learned alot. but i have *never* managed to find something that i
could get the element names from! getting element names was my first test
goal. i know they are in there somewhere, else you couldnt validate the
instance docs.
i finally decided that i could 'Declare Victory and Go Home' if i hacked
ASBuilder thusly:
ASModel asmodel = null;
asmodel = parser.parseASURI("./personal.xsd");
parser.setAbstractSchema(asmodel);
Document XS = parser.parse(new
DOMInputSourceImpl("","./personal.xsd",""));
walkPrint((Node)XS.getDocumentElement());
this is soooo lame! and it has serious consequences for memory
consumption.
so, to respond to your overall dev questions and link them to my desires:
a generic grammar caching interface that allows you to get at it just like
a DOM would be wonderful. an implementation of same should be provided as
well
it should be done as an interface and default implementation so that if a
user wants to save ram by choosing to 'forget' portions of the schema that
they dont need, they can just reimplement the cache accordingly.
tnx for allowing me the opportunity to put my oar in!
johnu
> Cheers,
> Neil
> Neil Graham
> XML Parser Development
> IBM Toronto Lab
> Phone: 905-413-3519, T/L 969-3519
> E-mail: [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]
