Re: Type modeling
From: David Frascone (davefrascone.com)
Date: 12 Oct 2001 21:17:58 -0000
Ok, now that I've had a chance to read this with my brain turned on . . .

I agree with all your preposals.

On Wed, Sep 19, 2001 at 04:50:07PM -0400, Mark Jones wrote:
> Dave,
> 
> > I don't think I like the change.  Could you please cite a pro and
> > con example
> > for me?
> 
> So the pros/cons in my last email were that unconvincing? Darn!
> 
> > IMO, I like the grouped stuff the way it is.  (And, as far as
> > code goes, mine already works *grin*)
> >
> 
> Hey, mine too :) If we change the DTD, I?d be looking at code changes too
> but I think they are fairly minor.
> 
> > So, convince me why we need to do this :)
> >
> 
> Well both DTDs obviously work so we?re down to the finer points of
> readability and intuitiveness. I have had two developers express confusion
> when trying to query the resulting DOM (?I queried the avp element for its
> type and it has none. Why??). After reading the data formats sections in the
> base draft I see their point.
> 
> I think it is important that the resulting XML be intuitive to people who
> have read the drafts and they would naturally expect every AVP to have a
> type attribute (Grouped and Enumerated are listed types).
> 
> The current DTD adds 2 extra XML elements (?type? and ?grouped?) just to add
> the constraint that non-grouped AVPs can not contain a group of AVPs. Why
> bastardize the DTD structure to enforce this constraint and not others that
> we know should exist? E.g. a AVP of types other than Integer32 can still
> have enums, type-name attributes in type elements can still reference avp
> names).
> 
> In summary, human readability and easy correlation to the drafts should be
> our priority for the XML. Lets leave applying the constraints to the XML
> Schema which at least provides some decent tools for the job.
> 
> Regards,
>        Mark
> 

  • (no other messages in thread)

Results generated by Tiger Technologies using MHonArc.