4 ms·

Wouldn't it be easier if this were XML instead of plain text? I assume the goal is that software can easily interpret the data.

• citricsquid 14y ago
  If everything follows the format (name: value) I can't see a reason why machine parsing would be difficult, I would guess the problem with XML (or any structure beyond plain text) is that it can be very daunting for technology inexperienced people.
• fesja 14y ago
  We want to be a human friendly file. If we had a JSON or XML file, it would be too complicated for a non-developer to write or read it. On this way, I think it doesn't matter if the website is done in wordpress, drupla, static files, flash, etc. It's just a simple file. Also, we are following the same pattern as the robots.txt file.
  • oellegaard 14y ago
    I would strongly suggest e.g. JSON or XML - if you can upload a website, the chance are that you could also create something like this. There would of course also be a template where absolute noobs could fill in the details and get correct output. With our current tools, implementing a clear text data storage seems like a pretty stupid idea - everyone would have to implement their own parsing. With e.g. JSON, there are libraries for every language and it has validation.
    • FuzzyDunlop 14y ago
      YAML, or the format used by Python's configParser or PHP's INI files (don't know what it's called), might be easiest. Less syntax and formatting. I'm not so sure about the proposal itself, though. For local, small businesses, how much can we assume about technical ability? If they have to pay the people who did their website to keep it up to date, how can we be sure they'll use it?
    • brittohalloran 14y ago
      Yeah I have to second this. No "non-techie" person will be updating this on their own, for the simple fact that they need to upload it after their done or edit it via ftp... etc. A wordpress plugin would help, but it still lacks great visibility to the business owner.
  • gav 14y ago
    The main issue I see with this philosophy is that you are pushing the responsibility for understanding the format upstream, similar to all the problems people used to have with malformed RSS feeds. If you want to have a feed of some kind that is machine-readable then you need to have a spec that is unambiguous. Using JSON or XML helps. Having a clear understanding of what could be in each field, including currencies, timezones, etc, is required.
  • engtech 14y ago
    YAML is the easiest combination of human and machine readable that has been implemented (so far). http://yaml.org/ http://yaml.org/
• dantheta 14y ago
  XML also has the advantage of declaring the character set of the content.
  • icebraining 14y ago
    I would say that nowadays there was no reason not to use UTF-8, but then I found out that Notepad still saves using ANSI as the format encoding. Damn you, Microsoft!
• alttab 14y ago
  What world do you live in where XML is easier? Have you ever written a SAX parser? XML parsing is not "easier". Screw the libraries that "do it for you". You still have to understand the tiered data structure, attributes vs content, namespaces,.... the list goes on. Understanding the schema and all that jazz is WAY more difficult than key: value. edit: Parsing is just as easy. Here is a one-liner in ruby: business_data = IO.readlines("business.txt").each_with_object({}) {|l, memo| k, v = l.split(':'); memo[k.strip] = v.strip }
  • fusiongyro 14y ago
    How does your parser handle malformed entries? How do you handle text encoding? What are the valid attributes, what constitutes valid text? XML is unsexy, but it's only complex because it addresses these issues up front. A clever one-liner doesn't make these issues go away, it just postpones them to an inopportune time later.
    • alttab 14y ago
      I see your point. The original post doesn't address these issues, and I'm not sure it is ever designed to. If someone wanted to create a globally accessed, multi-language, all-encoding supported fully validated business information XML-RPC protocol they certainly wouldn't have arrived at "business.txt". The main problem it was trying to solve is to prevent business owners from having to update their information everywhere it ends up - not to ensure proper encoding (99% of applications would be happy with UTF-8) and formatting. In almost all use cases simply copying what was there and plopping it into a string would be fine. Which brings me back to my point about XML. A lot of the time, XML produces complexity that simply isn't necessary. Following the 80/20 rule, designing it for your specific use case will be multitudes faster and work fine for your target audience, no need to build an enterprise system and standard global protocol out of the gate.
      • fesja 14y ago
        I couldn't have said better!
    • 14y ago