1478Re: [xml-dbms] Mapping List SimpleType
- Oct 2, 2001On the other hand Ron, it is better to have one orthogonal "trigger
interface" than it is to create a formatting API and ANOTHER non-orthogonal
set of API's to solve all the problems that a generalized trigger API could
solve. I'm not saying this is absolutely the way to go, but if there is
significant functionality related to the problem domain your software is
meant to address which is so commonly required by applications that large
numbers of people are constantly reimplementing it or working around its
lack, then it should be a legitimate candidate area for API extension.
Now, maybe its deemed that this sort of thing is best left to some other
library which is even MORE generalized and solves problems in domains not
directly addressed by XMLtoDBMS in which case you might simply contribute
input to some group that wants to develop it based on your needs.
It may also be that its an area that should be addressed but the resources
aren't now (or perhaps ever) available to tackle it, or that its very much
lower priority than something else. In that case it would be nice to just not
make too many assumptions in the API you DO have, so that in the future
people can generalize it.
This is one of the things I like best about perl as opposed to languages like
Java. Take the libwww interfaces (LWP), which provide both VERY simple
interfaces for casual use, and yet if you want to do something complex there
are portions of the API available for that too. Guess that was a rant, but
having spent the last couple months implementing XML processing systems in
perl I guess Java becomes less and less appealing...
On Monday 01 October 2001 03:16, you wrote:
> Yes, you convinced me.
> Simple is better.
> -----Original Message-----
> From: Ronald Bourret [mailto:rpbourret@...]
> Sent: zaterdag 29 september 2001 0:17
> To: email@example.com
> Subject: Re: [xml-dbms] Mapping List SimpleType
> Erik van Oosten wrote:
> > > I'm not willing to extend the interface -- I don't like using things in
> > > highly unintended ways <cut>
> > I am not sure this extension can be classified as highly unintended. If a
> > dateformatter gets the string '2001-01-42', what do you do? Returning
> > null may be appropriate, but you could also argue this is an example case
> > for
> > exception.
> You're right -- the methods in the interface do need to throw
> What I meant was that there is a difference between a formatting error
> and checking that a value is in a domain. For example, if you're parsing
> the integer "43", this is perfectly legal and I would find it an
> unintended use to check that the integer is between 5 and 10. I'll grant
> that it works and I wouldn't stop people from doing it, but I also
> wouldn't go out of my way to support it.
> I think the real question here is whether the class is a formatting
> class or a general, per-column trigger class. If we advertise it as a
> formatting class, then it's easy to implement and use. If we advertise
> it as a general trigger class, then it is a very short step to severe
> feature creep -- multi-column triggers, multi-table triggers, an
> interface to order pizza when the 500th row is inserted :), and who
> knows what else. I'd rather leave it as a formatting mechanism and not
> open a can of trigger worms.
> > > I don't think this is a problem. You can assign formatting classes on a
> > > per-property basis, so all you would need to do is declare one
> > > formatting class for each distinct data type and assign these to
> > > properties as necessary.
> > Hmmm, I wasn't clear enough. I meant context like the value of another
> > column (dbms->xml) or of another element/attribute (xml->dbms). But this
> > probably out of reach anyway.
> See what I mean? :) I wrote the above sentence about multi-column
> triggers before even reading this one.
> -- Ron
> To post a message, send it to: firstname.lastname@example.org
> To unsubscribe, send a blank message to:
> email@example.com Or join the newsgroup at:
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- << Previous post in topic Next post in topic >>