XML Disease



  • My company has caught a disease. Well, make that: we've purchased a CRM solution from a Canadian vendor aptly named after a huge U.S. government health organization.

    They are fully exposing the enterprisieness of their solution when one chooses to export data to an XML file.



    So, to represent a timestamp of, say, 5 June 2012, 15:03:50, they have come up with this marvel:

    <Respond_By_Date>2012-06-05 00:00:00</Respond_By_Date>
    <Respond_By_Time>1900-01-01 15:03:50</Respond_By_Time>
    

    They did have the common sense to store all timestamps in UTC, though.



  •  Perhaps somebody should explain standard XML Schema datatypes to them.



  • I don't think I would mind. It's clear, it's unique, it's easy to convert. Adding _Date and _Time to ...

    ... <job interview failure-style flush> ...

    OMG, now I see it. AAAAAARGH!



  • That is pretty incredible. But let's take it to the next level!! >:O

    <Respond_By_Year>2012-01-01 00:00:00</Respond_By_Year>
    <Respond_By_Month>1900-06-01 00:00:00</Respond_By_Month>
    <Respond_By_Day>1900-01-05 00:00:00</Respond_By_Day>
    <Respond_By_Hour>1900-01-01 15:00:00</Respond_By_Hour>
    <Respond_By_Minute>1900-01-01 00:03:00</Respond_By_Minute>
    <Respond_By_Second>1900-01-01 00:00:50</Respond_By_Second>
    

    AW YEAH!!



  • I was forced to do this last time because our CMS' inner-platform doesn't have a datetime type, only a date type which is actively rounded down to 00:00 for reasons I cannot begin to fathom. So I had to create an extra field for the time.



  • @dhromed said:

    I was forced to do this last time because our CMS' inner-platform doesn't have a datetime type, only a date type which is actively rounded down to 00:00 for reasons I cannot begin to fathom. So I had to create an extra field for the time.

     

    Is there a blurb about "leveraging Java to the business platform" or something like that? Because Java has this wonderful Date object which does precisely that to a valid datetime, and probably someone just auto-mapped it onto a database column. And since it was discovered after putting it in use, it's now part of the proven technology and a core asset of the content synergizer.



  • @TGV said:

    @dhromed said:

    I was forced to do this last time because our CMS' inner-platform doesn't have a datetime type, only a date type which is actively rounded down to 00:00 for reasons I cannot begin to fathom. So I had to create an extra field for the time.

     

    Is there a blurb about "leveraging Java to the business platform" or something like that? Because Java has this wonderful Date object which does precisely that to a valid datetime, and probably someone just auto-mapped it onto a database column. And since it was discovered after putting it in use, it's now part of the proven technology and a core asset of the content synergizer.

    WTF are you going on about? Java's java.util.Date object handles time very well, thank you very much. And since the SQL version, java.sql.Date, extends from java.util.Date, it handles them very well too. So, I ask again, what are you talking about?



  • We happen to use that same CRM package and are starting our upgrade to the next major version. In what version did you find this little gem? The old or the new?



  • @zelmak said:

    WTF are you going on about? Java's java.util.Date object handles time very well, thank you very much. And since the SQL version, java.sql.Date, extends from java.util.Date, it handles them very well too. So, I ask again, what are you talking about?

    He's talking about seamlessly architecting impactful markets by leveraging industry standard java.util.Date to appropriately deliver multimedia based intellectual capital mapped through collaborative world-class XML document deliverables.


  • ♿ (Parody)

    @Xyro said:

    @zelmak said:
    WTF are you going on about? Java's java.util.Date object handles time very well, thank you very much. And since the SQL version, java.sql.Date, extends from java.util.Date, it handles them very well too. So, I ask again, what are you talking about?

    He's talking about seamlessly architecting impactful markets by leveraging industry standard java.util.Date to appropriately deliver multimedia based intellectual capital mapped through collaborative world-class XML document deliverables.

    Obviously, but I wouldn't do it unless it also has secure mediation with frames.



  • @Joe Brummel said:

    They did have the common sense to store all timestamps in UTC, though.

    Bet you the rent money their validator doesn't allow for leap seconds. :)



  • @zelmak said:

    WTF are you going on about? Java's java.util.Date object handles time very well, thank you very much. And since the SQL version, java.sql.Date, extends from java.util.Date, it handles them very well too. So, I ask again, what are you talking about?

    Well I woudln't exactly say that, it's not at random that alternatives like Joda data have arisen and Android uses it's own datetime API...
    But I do highly doubt that Java stores a Date object as two complete timestamps, a date and a time part



  • @Xyro said:

    That is pretty incredible. But let's take it to the next level!! >:O

    <Respond_By_Millennium>2900-01-01 00:00:00</Respond_By_Millennium>
    <Respond_By_Century>1000-01-01 00:00:00</Respond_By_Century>
    <Respond_By_Decade>1910-01-01 00:00:00</Respond_By_Decade>
    <Respond_By_Year>1902-01-01 00:00:00</Respond_By_Year>
    <Respond_By_Month>1900-06-01 00:00:00</Respond_By_Month>
    <Respond_By_Day>1900-01-05 00:00:00</Respond_By_Day>
    <Respond_By_Hour>1900-01-01 15:00:00</Respond_By_Hour>
    <Respond_By_Minute>1900-01-01 00:03:00</Respond_By_Minute>
    <Respond_By_Second>1900-01-01 00:00:50</Respond_By_Second>
    

    AW YEAH!!


    FTFY



  •  Nah, you haven't caught full blown xml aids until you do what my place does:

    1. Ignore web.config or app.config for xml config settings, bar configuring a path and a filename in appSettings
    2. Deserialize external xml file from path in appSettings
    3. Deserialized object contains more paths to more files
    4. Repeat
    5. Don't use a schema for anything
    6. Don't make any of the objects serializable because one-way is faster, right?
    7. Copy and paste duplicate objects round the solution because creating a CommonConfig project would be too hard
    8. Log the exception message on deserialization, but not the stack trace so "object not set to an instance of an object" is actually fun to debug
    9. Make the whole thing derive from a generic singleton so you can't unit test anything properly

    Good point about storing timestamps though. I'll bring it up during the next techtalk I give, right after I explain what a foreign key constraint is.


Log in to reply