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] A question of necessity

On 25 April 2016 at 16:21, Steve Newcomb <srn@coolheads.com> wrote:
> 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.

I will stand corrected, but I do think that is the domain of NVDL.
I was thinking of validating (against a schema) at input / output.

> 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 must agree with that, even if it is quite local.
Do namespaces 'constrain' .. no, not on their own but together with
other bits of the XML stack,
they do assist with validation surely?

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

Do you mean shouting "It's your end, not mine"?

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

Thank you - do you believe they are still relevant (as in not outdated in
some aspects) today?

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

Wow, I should think it was... as it was to many others?

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

So to advance it's (still useful) ideas, it needs work? Or the parts still
relevant to the world of XML? If only the AF aspect?


Dave Pawson
Docbook FAQ.

[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