Re: [xml-dev] A question of necessity

[Steve Newcomb <srn@coolheads.com>]

On 04/25/2016 10:36 AM, Dave Pawson wrote:

Today Saxon / XSLT can validate the input and the output against some given
schema. I can't say that 'pointing a finger' is useful?
* the input is invalid
* the output is invalid
The transform is 'wrong' (in some way)?

Doing a particular transformation is not the same as being ready to point the finger of blame in the context of whatsoever transformation expects an instance of data to conform to the constraints for which conformance is claimed.

Are you implying that AF's can validate the transform itself? Something
tried, but not well accepted IMHO for XSLT.

I should have been clearer.  You asked about facilitating transformation in the context of 2 or even 3 namespaces.  I answered in terms of N architectures, all independent of one another except to whatever extent they independently claim to inherit constraints from one another.

In my personal (and fairly unpopular) view, pointing the finger of blame for
communications failures was always what SGML was all about, and the single
most important thing that XML got wrong was to remove the pointability of
the finger of blame.  Why even mention a "namespace" if it doesn't
*actually* constrain the structure and content of the data?  How does such
an annotation make the maintenance of a complex application of the named
information set more practical in a globalized, decentralized,
constantly-disrupting, rapidly evolving economy?  (Roger Costello's recent
note about the economy's lack of effective provision for change is relevant
here.)

I'm not comfortable in assuming a communication is always involved Steve?
Lots of transforms are used internally within an organisation?

How is a hunk of data not a message? How is a message not a communication?  Don't communications break down even within the tightest-knit and most-culturally-homogeneous organizations?

I wonder what the most common 'blame game' solution is today, when what I send
you does not match what you expect? Either before or after transformation?

In my experience, it's to ruefully decide to join some vendor's club of customers.

For me Steve, you haven't gone far enough explaining the ideas. Since
the original
documents are hidden in the way back machine, it might be nice if someone
with a dusty archive (AFAIK many of the gang of n supporting AF's are still
around?) could repost them on the 'live' web... even better, review the
key points (which I'm told we've re-invented quite a few times) and put up
the ideas with 20:20 hindsight.

You might want to start with http://hytime.org

It never went off the air.  It includes links to online representations of the final draft of the standard itself, and (I just looked) those links are still working this morning.

There you have it: AFs in a nutshell.  If you can grasp the idea, you can
readily grasp the comparative weaknesses and infelicities of colonized
names, at least in the context of global information interchange.

Is that putting too much of a constraint on AF usage? Was that a sole
purpose?

Well, HyTime does much more than AFs.  It also uses them a lot, for an amazing number and variety of things.  Did you know that it started its life as a standard for abstract music representation?  We generalized it after the Pentagon sent representatives to talk to a bunch of us musicians.  At the time, I was a music professor at FSU.  It was very strange for us.

HyTime's biggest problem is still its original one: it's very big, and it's written as an ISO standard.  It's a legal document sanctioned by the UN, and so it's more like a program that's full of macros than any readable piece of literature.  It rewards only the dedicated, patient, thoughtful re-reader.  As marketing, it stinks, and that's an understatement.  As a technical document, it's not bad at all, but it uses the original SGML formalism to express everything -- a formalism long out of favor, now.