| Re: Type modeling | <– Date –> <– Thread –> |
|
From: David Frascone (dave |
|
| 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.