AFs and the DPH (Was Animal Friends, etc.)

[Peter Murray-Rust]

At 07:10 30/09/97 -0400, Jonathan Robie wrote:
>At 09:35 AM 9/30/97 BST, Henry S. Thompson wrote:
>
>So now we have all the players!
>
Just one more player, please - the DPH (desperate Perl Hacker)... whom I
shall try to represent :-) [For those not on xml-sig, this mythical
character is assumed to be an eager customer for XML, and ignorant of SGML.
Everyone on XML-SIG used to agree that XML must be accessible to the DPH -
I hope that's still true. If it's not - and that XML is a commercial-only
enterprise - then I'll rethink things.]

As a hacker I know very little about AFs, but have been trying to find out
more from the SG/XML community. Many people (e.g. Eliot Kimber and James
Clark) have been very helpful but I suffer from not having:
	- a beginner's introduction to AFs on the WWW
	- simple free working software to see how they work
[If I'm wrong in this, I'll be delighted.]

It is clear that AFs have passionate supporters in the *ML community, but
their message isn't easily spread beyond it. My summary, gleaned over the
last year goes something like this:
	- AFs allow (partial) mapping of one data structure (in SGML) to another.
There are restrictions on mapping inconsistent content models, for example.
	- among the benefits of AFs are that you can manage different 'namespaces'
and can alias elements or attributes
	- AFs are defined in standard SGML and parsers parse them 'without
realising what they are' 
	- an AF expert can do very elegant things with AFs.

However, all the benefits from AFs have to be realised by having an
AF-aware processor (I differentiate parser from processor - an ESIS stream
could be input into an AF-aware processor). My understanding is that:
	- there are no freely available AF processors
	- generic AF processors are beyond the ability (or at least the time) for
a DPH to write from scratch

Therefore AFs are only available to largish groups with time and/or
money... This rules out the DPH.

I have the impression that AFs play the same sort of meta-role as
interfaces in Java. They organise things for you but don't actually write
any code for you! So a pre-requisite is an AF-engine.

These general problems come up with the XLL spec, where there is mapping of
attributes and elements. Maybe an AF engine makes implementing XLL easier -
certainly there is quite a lot of implied architecture in the spec.

I have consistently been asking whether it makes sense to build some
generic processing tools for XLL but the feedback that I seem to have got
is that this is application-dependent (i.e. different processors need to be
written for different DTDs). If so, this is a major deterrent to the use of
XLL and AFs. 

So - is this analysis anywhere near true? And if so, is the XML community
going to develop freely available tools for this type of requirement :-)?

	P.

Peter Murray-Rust, Director VSMS, domestic net connection
Virtual Hyperglossary specialities

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)