FedEx Tracking XML Schema



  • So a client wants to have some basic package tracking abilities integrated into their site, forcing me to dig into the bowels of UPS, FedEx, et. al's tracking APIs.

    They all seem to LOVE using XML (a total conspiracy by storage manufacturers and bandwidth providers to take all our money), and have big fancy DTDs and XSIs.

    Browsing through FedEx's documentation showed me one of the perils of attaching human-readable tags to data:

    ok tag: <PostalCode>
    huh? tag: <StateOrProvinceCode>

    In a system where they have tags like <SignatureProofOfDeliveryAvailable>['true' or 'false']</SignatureProofOfDeliveryAvailable>, they give an incorrect tag like <PostalCode>? Sure they mean <PostalOrZipCode>, or perhaps the more US-centric <ZipOrPostalCode>. Or maybe it's the other way around, and they should have taken out the Province option and just gone for a much more compact <StateCode>, or the quite-useable <State>.

    Oh, wait... that takes up less space and bandwidth... back to the drawing board... <CodeForLocalPoliticalJurisdictionWhichFallsBetweenMunicipalAndNationalInScopeAndSizeWithoutBeingOffensiveToAnyLocalesWhichMayUseDifferentTermsToReferToSuchDivisions>
     

     


     



  • I think a zip code can technically be considered a subset of postal codes, whereas states and provinces are unique to each other. 

    Then again, Virginia is a Commonwealth, not a state...And I think there's one that's a Republic, so they're not really being descriptive enough.
     



  • @vt_mruhlin said:

    Then again, Virginia is a Commonwealth, not a state...And I think there's one that's a Republic, so they're not really being descriptive enough.

    If you think that's bad, at my job I have to write about countries, which is fine and dandy till we get to Taiwan, Macau, and Hong Kong, all of which are kinda sort of maybe countries. But not really. Autonomously controlled regions, perhaps? Either way, it's really annoying finding language to get around that, which is why I'm happy to have an editor who can do that kind of thing for me :) 



  • And y'all wonder why we keep seeing frontpage articles of entire databases with columns named "Column001" through "Column999".  It's easier to type than most of the "politically correct" internal names you should be using.



  • The USPS refers to US postal codes as "ZIP codes" only because they felt it was necessary to trademark the term "ZIP code" (short for "Zone Improvement Plan").  The trademark has since expired.  Now we're stuck with a proprietary term that is of little value since it refers only to a specific subset of all postal codes, when there's nothing special at all about that subset.

    I consider it to be better practice to refer to all postal codes as simply "postal codes".



  • They used to use ZIPCode, and switched to PostalCode a few years back when they internationalized their web interfaces; the thinking was explicitly that ZIP codes were a subset of postal codes.

    It's StateOrProvince because it used to be State, then they added OrProvince when everything became available in Canada, and that was "good enough" as they continued to expand.

    I'm really surprised that they spelled it out instead of using &lt;SPODAvailable&gt;, though.  That's pretty much never spelled out internally.

     



  • @stationary said:

     

    It's StateOrProvince because it used to be State, then they added OrProvince when everything became available in Canada, and that was "good enough" as they continued to expand.

     

    But Canada has other places besides the ten Provinces.  What about Nunavut, Yukon and Northwest Territories?  For that matter, what about the U.S.'s Puerto Rico, Guam and the others?  It should be StateOrProvinceOrTerritoryOrPossessionOrProtectorate.  OhAndOrCommonweathToo.

     

     


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.