Re: Using TM to help define the future of XML

Andrew,

On Thu, 2010-12-02 at 15:06 +0000, Andrew S. Townley wrote:
> Hi Patrick,
> 
> DISCLAIMER: I blame any and all typos on the iPhone and the train! ;)
> 
> On 2 Dec 2010, at 02:28 p.m., Patrick Durusau <patrick-Q/[email protected]>  
> wrote:
> 
> > Andrew,
> >
> > Well, one top post deserves another! ;-)
> >
> > BTW, I would not get markup "history" from the xml-dev list. It is a
> > mixture of myth, mis-information and mis-understanding. MMM instead of
> > WWW if you will.
> >
> > XML was always about data as well as documents. You can search for Jon
> > Bosak's comments on that point.
> >
> > The "data" argument is one of those, "now we are awake" and different
> > from what went before sort of positions. Not based in reality or at
> > least no shared reality of those aware of what went before. ;-)
> 
> The sentiments that led to the above were a mixture of many observed  
> discussions on xml-dev, my own learning XML journey and my personal  
> bias to more document-centric hypermedia formats.  However, I take  
> your point. :)
> 
> This is also one area I see many less sophisticated developers  
> struggle with as well. Extremely simplistic XML data representions are  
> more the norm than the exception.
> 

True.

> > [I deleted a long digression on markup theory and history. Of interest
> > to few others and distracting from the point at hand.]
> 
> I'm always interested in history lest we repeat it, badly... ;)
> 

Yes, but in this case it would be controversial and distracting from
your main point. 

> > Markup (SGML/XML) made explicit certain information and encoded other
> > information implicitly (unless you have a DTD/Schema). HyTime was a
> > recognition that element names were simply markers for particular
> > structures that could be transitioned to other structures. (ok, I am
> > eliding a good bit, I want the post to fit into memory)
> >
> > So, yes, topic maps can expose the sort of information you are talking
> > about, but only at the expense of its identification.
> >
> > I am not sure the "let's program to data formats" crowd is going to  
> > see
> > any advantage in the explicit identification of data upstream from  
> > their
> > use of it.
> 
> Representation formats are only relevant so long as they are useful. I  
> think the heterogenous development envionments of today are driving  
> more people to this idea as it is almost always required to serialize  
> (convert or transform if you will) representations from one format to  
> another. Much time has been spent writing the plumbing to make this as  
> automagic as possible, but it still happens.
> 
> The problem is that the identity issue is generally ignored due to the  
> safety of the traditional application/system boundary and the implicit  
> identity space it defines.  I think the world has changed, and I don't  
> think this can be an unquestioned assumtion any longer.
> 
> Rather than losing the identification of the subject described by a  
> representation, I feel exactly the opposite would be possible.  Not  
> only would you be able to link representations to the subjects they  
> represent, but you can also explicitly identy both the semantics and  
> its encoding rules using the same mechanism.
> 
> Anyone who has ever built or used data mapping tools should be able to  
> enthusastically appreciate this expressiveness!
> 
> Why do you feel otherwise?
> 

I am not sure I "feel otherwise."

What I am questioning is whether "[others will] enthusiastically
appreciate this expressiveness!" ????

Example (from history): One (alleged) used case for topic maps was to
eliminate duplication of documentation for military systems. The
production of which was a line item in every contract and even if the
documentation was the same, the military was still paying for it.

Question: Some people wanted this to save money, be more efficient, etc.

Now, let's look at who did not want it:

1) Vendors of military systems, who by simply running a new cover page
or making minor changes, were charging full rate for a completely new
set of documentation. Consider that the documentation for an F-15 weighs
in at more than the aircraft and you get an idea of the documentation we
are talking about. This is pure gravy.

2) Contract managers, who the more contract $$$ they manage, the more
important their office, themselves, etc. 

3) The employees and contractors of the vendors who produce the
documentation for which the vendor charge yet again, increasing the
importance of the contract managers office.

And so on and so on.

So who are we going to sell this topic map system to, exactly? 

Personally I think the GAO, but we would have to demonstrate
non-conversion topic maps because there are too many information systems
to convert them into topic maps. We need to view them as topic maps. 

Consider it an "offensive" use of topic maps and subject identity. 

Anything we can't sensibly map, goes into the probable fraud column. ;-)
That would probably encourage cooperation on the issue of subject
identities. 

Hope you are having a great day!

Patrick



> > Still, if there were a very robust and easy to use method for explicit
> > identification and delivery of data into a variety of formats, it  
> > could
> > well be successful.
> 
> Indeed! :)
> 
> >>
> >> --
> >> Andrew S. Townley <[email protected]>
> >> http://atownley.org
> >>
> >
> >