Re: Using TM to help define the future of XML

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. ;-)

[I deleted a long digression on markup theory and history. Of interest
to few others and distracting from the point at hand.]

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. 

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. 

Hope you are having a great day!

Patrick 

 




On Wed, 2010-12-01 at 12:45 +0000, Andrew S. Townley wrote:
> Hi Patrick,
> 
> Hmm... where to start.  I'm top-posting this because it doesn't really lend itself to a point-by-point interpretation.
> 
> Part of my rationale here comes from my own work in mapping proxy representations in my own implementation to and from various representations including XML, XTM, CSV, Ruby objects, JSON "hashes", multisets (property bags), database schemas, document structures, system architectures, XML schemas and many other things over the last few years.  As a result, I've had to deal with trying to determine the right level of abstractions for what mattered as a proxy, and, depending on the task at hand, that level of abstraction varied wildly, as you might imagine.
> 
> Part of my rationale also comes from our discussion about the Atom <link> tag and the path Lars Heuer went down initially in treating the XML element itself as the property container (I've done this too, but this is a recent, public example).  I mentioned this difference in levels of abstraction before, but I didn't explore it because it wasn't at the heart of the discussion.
> 
> Two of the core issues facing XML, or any technology for that matter, are:
> 
>   a) suitability for purpose and
>   b) rate of adoption
> 
> In the past 6 years or so on the xml-dev mailing list, I've heard calls and proposals for many things to "speed up" or otherwise constrain XML information into a more machine-friendly format to enable faster processing of information in volume or in constrained environments like embedded systems, mobile phones, etc.  Make no mistake, XML is quite simply a representation syntax with a set of specifications around how to define vocabularies, traverse and query instances of those representations in an arguably straightforward and cross-platform manner.
> 
> As the xml-dev thread states, it started from a document-centric point of view, but was quickly adopted as a "text spreadsheet" or "text database table" format for displaying regularly structured information and then mixing that information in larger contexts.
> 
> Since XML is a syntax for representing things, if you want to efficiently transmit "things" or "information about things" in an easily expressible and non-binary manner, at some stage you need to start talking about the "things" themselves because you need to map that XML representation to or from databases, software objects, legacy network formats and the like.
> 
> However, if you only focus on the "things", you start to lose information about the structure of the relationships between those things that can easily be inferred from a tree-oriented, ordered format like XML (or any other explicit model like foreign keys in databases).
> 
> What you then need is a consistent way to articulate information about the representation and the thing it represents.  This is what Kurt essentially is saying might be necessary for XML's next steps.
> 
> We have something like that in the foundational TMRM and all of the higher-level specs that exist as fixed interpretations or concrete implementations of the TMRM with a fixed legend.
> 
> If you can base both of these requirements on a common model, then you can query, create, transform, map and express relationships between "things" in a way that allows moving between representations fairly trivially.
> 
> There have been some interesting JSON/XML hybrid things discussed along the thread, but the issue isn't JSON/XML.  I see the issue as being more fundamental, and one whose importance is grown as more and more people are trying to write software to describe and manipulate the same "things" or "information about things" using a variety of platforms, languages and specialized representations which are "optimized for purpose" within a particular context.
> 
> I'm suggesting that reminding people that such a model exists and could be applied (albeit with much bickering, blood, sweat and tears) to their problem might be a good thing for the world at large, as well as for Joe Average Software Developer.
> 
> This suggestion will never work without a consistent interpretation of identity, and I think the Topic Maps community has a pretty decent one of those.  Once you agree on how to identify "things" and how that identity assertion is made in various physical representations like XML, JSON, future-sexy-format-de-jour, etc., then perhaps the rest becomes a more straightforward exercise.
> 
> My current belief is that Topic Maps provides the necessary identity foundation and conceptual model (in the TMRM) for representing anything you want to say about anything using the physical representation of your choice.  The rest of the Topic Maps may just be extremely useful commentary on those fundamental points.
> 
> Why not share the love? :)
> 
> Cheers,
> 
> ast
> 
> On 1 Dec 2010, at 11:55 AM, Patrick Durusau wrote:
> 
> > Andrew,
> > 
> > Can you say a bit more about what you see as the "opportunity" here?
> > 
> > I am not sure that even if topic maps were to provide a 
> > 
> > "consistent mechanism for the depiction of both closed ontologies (XML)
> > and open ontologies (RDF/OWL)." (Kurt Cagle, below)
> > 
> > it would be of interest to people using the type of data that can be
> > conveyed with JSON.
> > 
> > Or are you suggesting that topic maps could act as an interface that
> > replies with an XML representation for some purposes and a JSON
> > representation for others? 
> > 
> > Doable but what areas do you see as wanting the capability for dual (or
> > more) representations? That doesn't happen for free.
> > 
> > (BTW, I don't know what Kurt means by open/closed so I am not conceding
> > it, just ignoring it.)
> > 
> > I won't reply to the rest of Kurt's points now but may in a future post.
> > 
> > Interested but still wondering what role you see topic maps playing? 
> > 
> > Hope you are having a great day!
> > 
> > Patrick
> > 
> > On Wed, 2010-12-01 at 10:16 +0000, Andrew S. Townley wrote:
> >> Hi Folks,
> >> 
> >> I know I cross-posed some of the chatter on XML-DEV recently, but it's gotten even more interesting and relevant.  There is growing recognition that if something proactive isn't done, things are going evolve in ways that aren't necessary good for the XML community.
> >> 
> >> Like my last set of posts, I think this is a potential opportunity to remind the XML community about Topic Maps, because of statements like:
> >> 
> >> On 1 Dec 2010, at 3:07 AM, Kurt Cagle wrote:
> >>> the XML standards community needs to understand that it has to reach out and recognize that the infoset can have multiple serializations, that not all those serializations are going to involve angle brackets, and that collections of content ultimately will end up becoming more important than individual documents. 
> >> 
> >> And in a separate email:
> >> 
> >> On 1 Dec 2010, at 3:17 AM, Kurt Cagle wrote:
> >> 
> >>> BTW, I'd also agree with Dave Pawson's point here. Maybe it's time to reinvent the wheel with an SXML. We know what worked and what didn't. We still have a fundamental disconnect between XML and Javascript that needs to be addressed, and attempting to do it within the rubric and process of XML looks to be a non-starter.
> >>> 
> >>> Some areas that I'd like to see -
> >>> 
> >>> 	• Creating a unified XML/JSON layer, including agreed upon serializations and working to extend both XML and JSON to be fully transferable.
> >>> 	• Creating a consistent mechanism for the depiction of both closed ontologies (XML) and open ontologies (RDF/OWL).
> >>> 	• Creating a consistent path/query layer between the syntactic (XQuery) and the semantic (SPARQL)
> >>> 	• Working with ECMA and the browser and mobile vendors to provide a universal first class SXML representation.
> >>> 	• A rethinking of distributed linking systems, especially in light of the emergence of RESTful architectures
> >>> These are big areas. They'll require that people check in preconceived notions at the door, and they will require champions that will be willing to both put in the effort to be the reference implementors and to defend the specifications from being co-opted by a given vendor.
> >> 
> >> Now, if you look at what they're really trying to do: come up with an abstract way to represent information and define a consistent path/query layer between syntax & semantics, that to me sure sounds like areas where the Topic Maps community might be able to help.
> >> 
> >> If you haven't read the whole thread yet (or you're not an xml-dev subscriber), I highly recommend the whole "James Clark: XML versus the Web" thread.
> >> 
> >> I don't want to re-hash the whole marketing issue again, but what, in pragmatic steps, can we as a community do to best engage with and participate in the subsequent rebirth/realignment of XML?
> >> 
> >> Cheers,
> >> 
> >> ast
> >> --
> >> Andrew S. Townley <[email protected]>
> >> http://atownley.org
> >> _______________________________________________
> >> topicmapmail mailing list
> >> [email protected]
> >> http://www.infoloom.com/mailman/listinfo/topicmapmail
> > 
> > 
> 
> --
> Andrew S. Townley <[email protected]>
> http://atownley.org
> 
_______________________________________________
topicmapmail mailing list
[email protected]
http://www.infoloom.com/mailman/listinfo/topicmapmail