Re: [xml-dev] A question of necessity

[Dave Pawson <dave.pawson@gmail.com>]

On 25 April 2016 at 14:49, Steve Newcomb <srn@coolheads.com> wrote:
> On 04/23/2016 10:18 AM, Dave Pawson wrote:
>
> Can [HyTime] A[rchitectual] F[orm]'s (or some variant) facilitate what a
> transform does with 2,
> possibly 3 namespaces?
>
> In think so, in at least one important sense, namely that when unexpected
> things happen (when information interchange fails), you'd be much better
> able to point the finger of blame somewhere specific, because the failure
> would have to be either in somebody's underspecified schema(s), or in
> somebody's failure to conform to the schema(s) to which conformance has been
> claimed.  (In SGML land, "...required to have been claimed".)

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)?

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

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

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?


>
> Another thing XML got wrong (in my personal and unpopular view) was its
> failure to provide for ad-hoc, user-defined hierarchies of inheritance of
> structural constraints, all of which, at every level of inheritance, would
> allow the finger of blame to be pointable whenever applications (such as
> transforms) fail to support reliable, accurate information interchange.
> This is the area where the HyTime Architectural Forms idea shines, and it's
> a very simple idea, really.  Here it is:
>
> The generic identifier (aka the "element type name", the "tag") of an
> element is nothing more or less than the value of the one-and-only nameless
> attribute.  Historically, it has been used to specify the applicable
> constraints on its other attributes and on its content, but there is no
> fundamental reason why it has to be specially privileged over any other
> attributes in that respect.  Lots of attributes can fulfill that function
> simultaneously.  In fact, there can be as many constraint sets as there are
> attributes -- and many more if the constraint sets themselves are
> inheritable by other constraint sets.
>
> In AF jargon, a constraint set is called an "architecture".  HyTime provides
> a familiar syntax, called "meta-DTDs", for specifying the inheritable
> syntactic constraints of any given architecture.  Every existing DTD can be
> regarded and directly (and trivially) used as a meta-DTD.  HyTime itself is
> an example of an architecture, the syntactic constraints of which are
> expressed in the "HyTime meta-DTD".

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.


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


 You can
> also figure out why I believe that HyTime is beautiful to those who want
> global information interchange to thrive, and that it's dangerously
> subversive, and perhaps even blasphemous, to those who feel that successful
> global competition necessarily requires an anti-modular, monopolistic
> attitude towards the expression and interchange of information, and to the
> development of software that exploits such information.

<grin/> I wonder which side Steve is on!



>
> Personally I think it's in the public interest:
>
> to let millions of flowers bloom,
>
> to support the ever-growing complexity of human semantics and human affairs,
> and
>
> to decentralize control over what can be said and how it can be said,
>
> while yet enabling ever-better information interchange.  So, I still like
> HyTime very much.  Even in exile and in rags, she looks as beautiful as ever
> to me.
>
>
> Steve Newcomb

Gentle round of applause! You're not on your own Steve. The number of times
AF's have arisen on xml-dev surely could be justification for a  new look?
Or at least a review in light of more recent usage / experience?

====================

An aside. Arjun Ray pointed out
"But to me the basic purpose of attributes in SGML, based on my reading
of Goldfarb's Handbook, is to encode referential information (IDREF,
ENTITY(IES), NOTATION, and of course NMTOKEN(S); "

I do wonder what might be made of todays XPATH expressions, that for some,
can take up pages, never mind a lot more than the above!

regards






-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk