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.

     

     


  • 🔀

    Welcome to "Hunt the Wumpus"
    ­The Wumpus lives in a cave of 20 rooms. Each room has 3 tunnels leading to other
    ­rooms. (Look at a dodecahedron to see how this works -- if you don't know what a
    ­dodecahedron is, ask someone.)
    ­
    ­Hazards:
    ­Bottomless pits: Two rooms have bottomless pits in them. If you go there, you
    ­fall into the pit and lose.
    ­Super bats: Two other rooms have super bats. If you go there, a bat grabs you
    ­and takes you to some other room at random. (Which might be troublesome...)
    ­
    ­Wumpus:
    ­The Wumpus is not bothered by the hazards -- he has sucker feet and is too big
    ­for a bat to lift. Usually he is asleep. Two things wake him up: you entering
    ­his room or you shooting an arrow.
    ­If the Wumpus wakes, he either stays still or moves through one tunnel. After
    ­that, if he is where you are, he eats you up (and you lose).
    ­
    ­You:
    ­[MORE]

  • Notification Spam Recipient

    @error_bot Erm.... wut?


  • Considered Harmful

    @Tsaukpaetra said in FedEx Tracking XML Schema:

    @error_bot Erm.... wut?

    Oh, shit. Got the wrong topic ID again.



  • I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.


  • area_pol

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    Don't ever say a good thing about XML. That's, like, programming 101, especially on forums bitching about programming - like this one.



  • @strangeways said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    Don't ever say a good thing about XML. That's, like, programming 101, especially on forums bitching about programming - like this one.

    Overall, the problem with XML is not that it's XML. It is what it is. No, the problem is the myriad of bad ways that people use it.


  • Discourse touched me in a no-no place

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML.

    It's not too bad. JSON is marginally better for a data interchange format (fewer strange things) but XML is mostly not too bad, and for some tasks such as occasionally producing output that both people and computers can read, XML is actually better than JSON. (CSV only really works for tabular data.)

    All the above are light years better than most of the other alternatives. For example, YAML seems to be almost entirely made out of strange syntax…


  • Banned

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML.

    The thread is from 13 years ago. Things were different back then. For example...

    If the verbosity is offensive, it compresses very nicely

    ...HTTP compression was very rare.



  • @Gąska said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML.

    The thread is from 13 years ago. Things were different back then. For example...

    If the verbosity is offensive, it compresses very nicely

    ...HTTP compression was very rare.

    I refer you to RFC 1945 of 1996, which formally defined an experimental compression token for HTTP/1.0, which was formalised as a "real" token in HTTP/1.1 the following year in RFC 2068. Thirteen years ago, HTTP/1.1 was already ten years old, more than enough time for it to be "normal". It's also worth noting that compressing HTTP-delivered content was more important back then - available bandwidth has increased far more since then than our absolute use has. (Heck, it wasn't until quite recently that one could even dream of a home-user on a consumer contract downloading anything from the Internet at 110 MB/second, but I can do that, and, more to the point, I have done that.)


  • Banned

    @Steve_The_Cynic said in FedEx Tracking XML Schema:

    @Gąska said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML.

    The thread is from 13 years ago. Things were different back then. For example...

    If the verbosity is offensive, it compresses very nicely

    ...HTTP compression was very rare.

    I refer you to RFC 1945 of 1996

    And Unicode was even older. Do you know when most websites stopped shitting all over themselves when you wrote "ą"?

    Edit: why even bother with Unicode. I could just mention IPv6.


  • Discourse touched me in a no-no place

    @Gąska HTTP is built on top of the solutions for the problems with mail and newsgroups. Apart from the initial protocol line, it uses the same general message scheme.



  • @Gąska said in FedEx Tracking XML Schema:

    @Steve_The_Cynic said in FedEx Tracking XML Schema:

    @Gąska said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML.

    The thread is from 13 years ago. Things were different back then. For example...

    If the verbosity is offensive, it compresses very nicely

    ...HTTP compression was very rare.

    I refer you to RFC 1945 of 1996

    And Unicode was even older. Do you know when most websites stopped shitting all over themselves when you wrote "ą"?

    Edit: why even bother with Unicode. I could just mention IPv6.

    That would be those long addresses all full of letters and colons that I have on my network, right? The ones beginning 2a01?


  • Considered Harmful

    @Gąska said in FedEx Tracking XML Schema:

    when you wrote "ą"?

    I don't even know how to do that, nor would I want to. 🍹


  • Banned

    @Steve_The_Cynic yes, that one. It was standardized in 1998. How many years have passed until you finally could use it to connect with this forum?



  • The problem with XML is that it's taking the principles of a document markup format and attempting to apply it to data serialization. Marked-up documents are heavy on data content and relatively light on markup tags; data serialization is the opposite, so you end up with a massive flood of "tag soup" drowning out the data you're attempting to communicate.

    JSON can communicate all the same information that XML can, but it's significantly smaller, making it faster to download, and simpler, making it both easier for humans to read and faster for computers to parse.


  • Java Dev

    @error said in FedEx Tracking XML Schema:

    @Gąska said in FedEx Tracking XML Schema:

    when you wrote "ą"?

    I don't even know how to do that, nor would I want to. 🍹

    Compose, ,, a


  • Banned

    @Mason_Wheeler the only problem with JSON is that schema validation is still in its infancy. Okay, there's been significant developments last year so it's more like kindergarten now - but still not enough for any serious use. Especially the lack of tooling is problematic.



  • @Gąska said in FedEx Tracking XML Schema:

    @Mason_Wheeler the only problem with JSON is that schema validation is still in its infancy.

    JSON schemas and validation are available now - I'd say the problem is actually that not enough people use them, not that it isn't there.

    Though there's no reason you shouldn't write JSON against an XSD, except that it would be weird and confusing. Wait, maybe that was a reason :)


  • Banned

    @bobjanova said in FedEx Tracking XML Schema:

    @Gąska said in FedEx Tracking XML Schema:

    @Mason_Wheeler the only problem with JSON is that schema validation is still in its infancy.

    JSON schemas and validation are available now - I'd say the problem is actually that not enough people use them, not that it isn't there.

    I love when people reply before reading the post in full.

    Though there's no reason you shouldn't write JSON against an XSD

    I can think of at least two: child elements and namespaces. No matter how much the edgy teenagers in charge of modern software development would want you to think otherwise, XML and JSON are not isomorphic.



  • @Gąska said in FedEx Tracking XML Schema:

    I can think of at least two: child elements and namespaces

    "element": {
       "@namespace": "com.initech.myproject",
       "childElement": { 
          "stuff": "goes here"
       }
       "stuff": "goes here"
    }
    

  • Banned

    @Mason_Wheeler I didn't say you can't fake it. I said they're not isomorphic.

    Also, tag names. Tag names themselves carry important information. There's no such concept in JSON either. Yes, you can fake it, but...

    {
      "@tag": "root",
      "@children": [
        {
          "@tag": "element",
          "stuff": "goes here",
          "@children": [
            {
              "@tag": "childrenElements",
              "@children": [
                {
                  "@tag": "childElement",
                  "id": 1
                },
                {
                  "@tag": "childElement",
                  "id": 2
                },
              ]
            }
          ]
        }
      ]
    }
    

    ...good luck convincing anyone to write their JSONs like that. And that's the only way to make it possible to validate JSON document against an XSD.

    For the record, the XML above is the following:

    <root>
      <element stuff="goes here">
        <childrenElements>
          <childElement id="1"/>
          <childElement id="2"/>
        </childrenElements>
      </element>
    </root>
    

  • Considered Harmful

    @PleegWat said in FedEx Tracking XML Schema:

    Compose

    You're just making shit up now.


  • Java Dev

    @error said in FedEx Tracking XML Schema:

    @PleegWat said in FedEx Tracking XML Schema:

    Compose

    You're just making shit up now.



  • @Gąska said in FedEx Tracking XML Schema:

    Tag names themselves carry important information. There's no such concept in JSON either.

    The equivalent concept is the name on name/value pairs. And yeah, you wouldn't write the JSON that way. You wouldn't have to, since JSON has a concept of arrays which makes it far less bulky than XML's version.


  • Banned

    @Mason_Wheeler said in FedEx Tracking XML Schema:

    @Gąska said in FedEx Tracking XML Schema:

    Tag names themselves carry important information. There's no such concept in JSON either.

    The equivalent concept is the name on name/value pairs. And yeah, you wouldn't write the JSON that way. You wouldn't have to, since JSON has a concept of arrays which makes it far less bulky than XML's version.

    Remember that we were talking about validating JSON against XSD. Of course it's not a problem that JSON doesn't match XML exactly if you don't need JSON to match XML exactly - but here you do.

    I mean, you would if you were doing it. But it's a stupid idea to start with, so I VERY MUCH HOPE YOU DON'T.



  • @Gąska said in FedEx Tracking XML Schema:

    I can think of at least two: child elements and namespaces. No matter how much the edgy teenagers in charge of modern software development would want you to think otherwise, XML and JSON are not isomorphic.

    You are right, JSON and XML are not isomorphic - but not because it is hard to map XML to JSON, but because if you have one mapping from any of the two to the other, you are restricting the allowed documents of the other to an arbitrary subset. For example, [null] will almost never map to some XML document (if you don't define some very strange mapping, but please tell me why [null] should map to <foo/> other than just because you arbitrarily defined it like that).

    But you can get to a subset of JSON which matches XML without being too verbose. For example, we could define that a JSON object only has one field which defines the tag name and contains an array of its children. Attributes are then represented as a special case by using the first element of that array as an object of key/value pairs for the attributes. Thus, your example becomes:

    {
      "root": [
        {},
        {
          "element": [
            { 
              "stuff": "goes here"
            },
            {
              "childrenElements": [
                {},
                {
                  "childElement": [
                    {
                      "id": "1"
                    }
                  ]
                },
                {
                  "childElement": [
                    {
                      "id": "2"
                    }
                  ]
                }
              ]
            }
          ]
        }
      ]
    }
    

    Now this is still much more verbose than your XML. But at least we are not repeating "@tag" all the time. We can even do better. If we define attributes to start with an @, we can get rid of these strange empty objects:

    {
      "root": [
        {
          "element": [
            {
              "childElements": [
                {
                  "childElement": [],
                  "@id": "1"
                },
                {
                  "childElement": [],
                  "@id": "2"
                }
              ]
            }
          ],
          "@stuff": "goes here"
        }
      ]
    }
    

    If you remove the whitespace from this and the XML, the JSON version is even a few characters shorter. It is still not exactly what a normal person would write, but it looks at least a little bit more natural. The main problem I see with that however that it is crippling your JSON just so you can use another technology, namely XML schema. But you can't use numbers, booleans or nulls now without thinking how this will mapped back to XML so you can validate it. Just take a string representation? But what if a field is not allowed to be null and contains the string "null"? Or you don't want to have such a fixed structure for your document? Dealing with XML namespaces and child elements is quite easy compared to that.

    So yeah, seems like using XML validation for JSON is using the wrong tool for the job and if you do it, make sure the next developer who has to deal with that mess doesn't know where you live.



  • @Gąska said in FedEx Tracking XML Schema:

    @Steve_The_Cynic yes, that one. It was standardized in 1998. How many years have passed until you finally could use it to connect with this forum?

    Well, given that what.thedailywtf.com still doesn't have an AAAA record, that qualifies as a trick question. But I've had those addresses (a whole /56, no less) since 23 December 2016.


  • Banned

    @Steve_The_Cynic said in FedEx Tracking XML Schema:

    But I've had those addresses (a whole /56, no less) since 23 December 2016.

    That's how many days since standardization? And what makes you think HTTP compression went any better? AFAIK it was only in mid-2010s that compression really took off, about the same time as HTTPS for non-sensitive content.


  • Java Dev

    @Gąska said in FedEx Tracking XML Schema:

    @Steve_The_Cynic said in FedEx Tracking XML Schema:

    But I've had those addresses (a whole /56, no less) since 23 December 2016.

    That's how many days since standardization? And what makes you think HTTP compression went any better? AFAIK it was only in mid-2010s that compression really took off, about the same time as HTTPS for non-sensitive content.

    IIRC, for quite a long time it was stated that you could never compress an HTTP request, since a priori you did not know whether the server would be HTTP/1.1 compliant so you'd always have to generate HTTP/1.0 requests to hedge your bets.



  • @Steve_The_Cynic said in FedEx Tracking XML Schema:

    But I've had those addresses (a whole /56, no less) since 23 December 2016.

    I still don't have IPv6. Because Vodafone.



  • @Gąska said in FedEx Tracking XML Schema:

    Also, tag names.
    ... are just the name of the property.

    For the record, the XML above is the following:

    <root>
      <element stuff="goes here">
        <childrenElements>
          <childElement id="1"/>
          <childElement id="2"/>
        </childrenElements>
      </element>
    </root>
    

    The equivalent JSON for this is not the monstrosity you posted, but

    root: {
     element: {
      stuff: 'goes here',
      childrenElements: [
        childElement: { id: 1 },
        childElement: { id: 2 }
      }
     }
    }

    Except you probably wouldn't bother with the pointless root wrapper node either.

    Namespaces I'll give you, although JSON-LD's @context property pretty much fills the same need. But how often do you actually need to define the namespace in the XML document itself? You only need that if you're accepting any old XML and using the namespace to switch how to process it - most XML reading already knows what namespace and schema it should check against (it's either a config file or it's a well defined API endpoint).


  • Banned

    @bobjanova said in FedEx Tracking XML Schema:

    The equivalent JSON for this is not the monstrosity you posted, but

    root: {
     element: {
      stuff: 'goes here',
      childrenElements: [
        childElement: { id: 1 },
        childElement: { id: 2 }
      }
     }
    }

    Is this an array property? Do you realize XML doesn't have array properties?

    I wasn't talking about functionally equivalent. I was talking about structurally equivalent. To the degree that allows you to validate your JSON documents against XML Schema Definitions. Have you ever seen XML Schema Definition?

    The bottom line is - JSON sucks because schemas aren't supported widely enough to be useful, and XML sucks because of everything else. And you should never pretend that one is the same as the other, because you're only going to end up in even more pain.



  • XML/JSON arguments... everyone is wrong, oh and everyone will disagree with me on this.

    They each have their purpose and those purposes are nearly identical but not the same.

    JSON should be used when you are transporting data but do not care to have a verifiable structure. It is lightweight, compact and easy to parse.

    XML should be used when you need to verify against a defined structure. Yes it is bloated but that is the payoff but it is also easy to parse.

    Neither is better then the other in general but one is better then the other in certain situations. Many developers get caught up in the "OMG XML IS SO BLOATED" argument that they have no clue about what the benefits are, they stop at the hard structure and forget everything else.
    Others say they need the verifiable structure when they really don't and use XML when JSON should be the proper choice.

    Now everyone go ahead argue against me. I'll just know you are already wrong.



  • @Gąska said in FedEx Tracking XML Schema:

    JSON sucks because schemas aren't supported widely enough to be useful,

    What useful thing is JSON Schema not able to do?


  • Banned

    @Mason_Wheeler generate schema-specific classes for fast and easy reads and writes. Now you're going to say, "but that's tooling problem, not JSON Schema problem!" - to which I'll reply, "but that's exactly my point - the tooling sucks!"

    Do you know how many implementations are stuck on Schema version 4? I'll tell you: a lot of them. It's because there's been a three year period where JSON Schema wasn't updated at all despite still being largely incomplete. And when the spec was finally updated, the implementations weren't, so you can shove the new spec up your ass because that's the only thing it's good for, provided you print it out first because with the electronic version you can't even do that.


  • kills Dumbledore

    Can we get back to hunt the wumpus now?



  • @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    XML doesn't always translate well to CSV, so that isn't a very good comparison. A better comparison would be XML versus JSON.

    EDIT: Yeah, I'm a day late. So what?



  • @abarker said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    XML doesn't always translate well to CSV, so that isn't a very good comparison. A better comparison would be XML versus JSON.

    EDIT: Yeah, I'm a day late. So what?

    Well, in my use case, it did. Going from compressed XML to compressed CSV (since the data was tabular and didn't contain nested hierarchies) yielded meager gains. Comparing compressed XML vs. compressed JSON is left as an exercise to the reader.



  • @Groaner said in FedEx Tracking XML Schema:

    Comparing compressed XML vs. compressed JSON is left as an exercise to the reader.

    Lorne-Kates Fuck you, pay me.


  • Banned

    @Groaner said in FedEx Tracking XML Schema:

    @abarker said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    XML doesn't always translate well to CSV, so that isn't a very good comparison. A better comparison would be XML versus JSON.

    EDIT: Yeah, I'm a day late. So what?

    Well, in my use case, it did.

    And in my use case, converting Bash shell script into Windows batch file was a matter of changing file extension. There's a reason people say anecdote is no evidence.



  • @dfdub said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    Comparing compressed XML vs. compressed JSON is left as an exercise to the reader.

    Lorne-Kates Fuck you, pay me.

    No one's forcing you.



  • @Gąska said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    @abarker said in FedEx Tracking XML Schema:

    @Groaner said in FedEx Tracking XML Schema:

    I don't get the hate for XML. If the verbosity is offensive, it compresses very nicely, such that compressed CSV offered less than a 15% reduction in archive size over compressed XML in some testing I did.

    XML doesn't always translate well to CSV, so that isn't a very good comparison. A better comparison would be XML versus JSON.

    EDIT: Yeah, I'm a day late. So what?

    Well, in my use case, it did.

    And in my use case, converting Bash shell script into Windows batch file was a matter of changing file extension. There's a reason people say anecdote is no evidence.

    Fascinating. I don't recall signing up to be the world's foremost authority on file format storage efficiency - I signed up to make an offhand comment about how a supposedly bloated file format compressed surprisingly well in my testing. To anyone familiar with how compression algorithms work, this should be non-intuitive, but interesting. Is there a new rule around here where we're all expected to post from a position of authority with reams of data to back up our statements? If so, I'm going to hold the rest of you to it and I expect post volume to plummet accordingly.


  • Discourse touched me in a no-no place

    @abarker said in FedEx Tracking XML Schema:

    A better comparison would be XML versus JSON.

    Sounds like it'd be a tedious discussion 🐠


Log in to reply