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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Rethinking namespaces, attribute remapping (was Re: [xml-d

[ Lists Home | Date Index | Thread Index ]
  • To: "Sean McGrath" <sean.mcgrath@propylon.com>,<xml-dev@lists.xml.org>
  • Subject: RE: [xml-dev] Rethinking namespaces, attribute remapping (was Re: [xml-dev] TAG on HLink)
  • From: "Mark Seaborne" <MSeaborne@origoservices.com>
  • Date: Mon, 30 Sep 2002 12:05:56 +0100
  • Thread-index: AcJm2FpYwlV0pMZdQBqqMUanqj/ztQBkMBNg
  • Thread-topic: [xml-dev] Rethinking namespaces, attribute remapping (was Re: [xml-dev] TAG on HLink)

-----Original Message-----
From: Sean McGrath [mailto:sean.mcgrath@propylon.com]
Sent: 28 September 2002 11:14
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Rethinking namespaces, attribute remapping (was
Re: [xml-dev] TAG on HLink)

>To that I would add, that interoperability via standardised schemas has
>been on the road for decades now and has, um, failed to deliver.
>Namespaces are just one more part of that sui generis schema world view.
>Is it time to declare this entire formulation of the solution
>simple, elegant and wrong?

>Perhaps constant context-dependent, on-the-fly
>transformation is the only truth?

Honestly its not so bad! After a number of years doing little else other than transforming EDI into other things, and then back the other way again, I have become quite indifferent to the multitude of ways people have of storing and describing data/information. As long as you CAN get at it, and CAN understand what the originator thinks it means, who cares what it looks like really?

The lesson I have learned, that even now never ceases to astound me, is just how little understanding of or control over their electronic inputs and outputs many organisations have. The number of times we have just had to go live and see what comes out! Makes you appreciate just what a powerful combination paper and human beings are.

I agree with your conclusion (in the referenced article) that XSLT is not the complete answer for transformation, no matter how tempting it might be to think it is at first (I still fall into that trap sometimes). But then nor was it intended to be, which is probably one of the reasons why it is so useful in the first place. I try only to use it to transform structure, and do as much content transformation in another place, where I have more control.

In fact a company for which I used to work came up with a "middle ground" XML like structure which was designed specifically to support transformation. All data structures went through this simple, lightly hierarchical structure, en route to something else (normally via rather complex rules involving a message-base and lots of user interaction). This point of message stability in the middle meant that transformations were simpler, mappings were significantly fewer than they might have been, and, most importantly of all, we were able to cope.

The fact that transformation is normally possible, and often not too horrible, makes our world, where if something CAN be said in more than one way, it WILL be said in more than one way, much less worrisome. Look at the amounts of XSLT sprinkling the HLink/XLink discussions of late!  

And here's me working for an XML Standards body now!

All the best

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>


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

Copyright 2001 XML.org. This site is hosted by OASIS