Loading ...
Sorry, an error occurred while loading the content.

RE: [xml-dbms] Mapping List SimpleType

Expand Messages
  • Erik van Oosten
    Yes, you convinced me. Simple is better. Erik. ... From: Ronald Bourret [mailto:rpbourret@rpbourret.com] Sent: zaterdag 29 september 2001 0:17 To:
    Message 1 of 16 , Oct 1, 2001
    • 0 Attachment
      Yes, you convinced me.
      Simple is better.

      Erik.


      -----Original Message-----
      From: Ronald Bourret [mailto:rpbourret@...]
      Sent: zaterdag 29 september 2001 0:17
      To: xml-dbms@yahoogroups.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
      an
      > exception.

      You're right -- the methods in the interface do need to throw
      exceptions.

      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
    • Tod Harter
      On 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
      Message 2 of 16 , Oct 2, 2001
      • 0 Attachment
        On 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.
        >
        > Erik.
        >
        >
        > -----Original Message-----
        > From: Ronald Bourret [mailto:rpbourret@...]
        > Sent: zaterdag 29 september 2001 0:17
        > To: xml-dbms@yahoogroups.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
        >
        > an
        >
        > > exception.
        >
        > You're right -- the methods in the interface do need to throw
        > exceptions.
        >
        > 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: xml-dbms@yahoogroups.com
        > To unsubscribe, send a blank message to:
        > xml-dbms-unsubscribe@yahoogroups.com Or join the newsgroup at:
        > news://news.barkto.com/homeless.xml.xml-dbms
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Ronald Bourret
        I think you make some good points. (Well-written rants are fun, too. :) I agree that generalized APIs are a good idea, as long as you don t lose track of the
        Message 3 of 16 , Oct 2, 2001
        • 0 Attachment
          I think you make some good points. (Well-written rants are fun, too. :)

          I agree that generalized APIs are a good idea, as long as you don't lose
          track of the problem you are trying to solve. In this case, the problem
          is formatting and I think the proposed solution meets the requirements
          of being general.

          (Nobody has ever asked for triggers, so it is a very, very low priority.
          Two other reasons for not supporting triggers are lack of manpower and
          the fact that I try to avoid adding things to XML-DBMS that exist
          somewhere else. Since databases already have triggers, I see no reason
          to add them to XML-DBMS.)

          -- Ron

          Tod Harter wrote:
          >
          > On 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...
        Your message has been successfully submitted and would be delivered to recipients shortly.