OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] How to do XML design, per Jackson Structured Design

On 11/27/13 10:10 AM, Simon St.Laurent wrote:
On 11/26/13 7:47 PM, Uche Ogbuji wrote:
On Thu, Nov 21, 2013 at 1:28 AM, Michael Kay <mike@saxonica.com
<mailto:mike@saxonica.com>> wrote:
  One thing that Jackson misses, though, is that there can be multiple
  hierarchic views of the data: this doesn't apply to the indexed
  sequential files he was originally working with, nor (directly) to
  XML, but it does apply when you extend Jackson to other fields.

THIS! Just this! In the day job I spend a lot of time explaining to
people that too many mainstream systems try to organize information with
one hierarchy to rule them all, or even worse, they degenerate the one
hierarchy into a tabular form. In my experience, most real world bodies
of information have multiple possible hierarchical views, and an
enormous number of IT problems boil down to juggling the political
pressures of prioritizing one view of the data over another within an
organization, and with respect to different populations served by the
Agreed - THIS!

When organizations get past the initial XML culture shock issues (they don't always), this seems to be the largest long-term challenge. In many ways, it's what drives the quest for brittleness I've seen and heard about too many times.

It also seems to be what drives some folks to RDF, where hierarchies receive less worship.

Interesting ... seems to be a very broad generalization, and I think the situation differs in different domains.

In my view for text (hypertext, whatever), hierarchies + some light linking seems to be a pretty good model. For business process modeling, geometrical objects, social relationship graphs, maybe not. At least the links become more important than any hierarchy, which is secondary.

When you import / export / transfer in bulk, you are treating your data *as a text* so the hierarchy is useful since at that moment you don't particularly care about the relationships (they are not important for the integrity of archiving/transport), you just want to treat your data as a big hunk of stuff to be moved around, saved, etc, treated as a giant unit. This idea breaks down somewhat with smaller messages since relational integrity becomes impossible to maintain across loosely-coupled systems without imposing rigid top-down constraints on the evolution of the data.

But when you are computing (rendering 3d models, searching relationship graphs, performing trend analysis etc), the relationships, indexes, etc: things that cut across the hierarchy in multiple dimensions, are what matters, not the rigid immutable structure that XML models well.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS