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

[Paul Prescod]

Peter Murray-Rust wrote:
> 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.]

XML must be useful to the DPH for simple processing. Nobody has ever
claimed that (s)he would be able to do anything that XML could do.
That's why we are even still *considering* parameter entities. Nobody
expects the DPH to handle them. They should just ignore them and process
the content of the document to do whatever massaging or transformation
they wanted to do.
 
> 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.]

nsgmls is simple, free working software that supports AFs nicely. I'm
sure Eliot has written a hundred tutorials. The reason that AFs are hard
to learn (in my opinion) is because they mix concepts that in most
people's experience are separate: interfaces and transformations. If you
think of them only as interface inheritance, you miss half of it. If you
think of them only as transformations you also miss some of it.
 
>         - AFs allow (partial) mapping of one data structure (in SGML) to another.
> There are restrictions on mapping inconsistent content models, for example.

As with any non-Turing complete transformation technology. (although you
could imagine a transformation technology that is more powerful than AFs
but not Turing complete)

>         - among the benefits of AFs are that you can manage different 'namespaces'
> and can alias elements or attributes

Yes and no. Imagine you use AFs to map from a CML document to an HTML
document (if their models are close enough). Then obviously the element
type names in the latter are in a different namespace (the HTML DTD)
than the names in the former (the TEI DTD). Usually when you think about
"managing namespaces" you are looking for some mechanism of *combining
them* and making a single, combined namespace, not merely providing
alternate names for every element, one in one namespace and another in
another namespace.

>         - AFs are defined in standard SGML and parsers parse them 'without
> realising what they are'

That's true. The parser just passes them to the AF engine as attributes.

>         - an AF expert can do very elegant things with AFs.

Elegant? I can't say, it's too subjective. Powerful and convenient? Yes.
 
> 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

NSGMLS (and thus Jade) embeds one.

>         - generic AF processors are beyond the ability (or at least the time) for
> a DPH to write from scratch

I dunno. Since only a few people have done it I don't know much about
the algorithms that are necessary. A simple AF subset would probably be
pretty easy. It would be a simple 1 to 1 mapping from elements in one
DTD to elements in another. What's so difficult about that?
 
> Therefore AFs are only available to largish groups with time and/or
> money... This rules out the DPH.

Not true. I use them by myself for tiny little projects. The smaller the
project the more I benefit from them. Writing a full transformation
program in Python or Perl is cost effective for large projects with many
documents conforming to a single DTD. But if I write a DTD for one
document then I don't want to go to that hassle so I just use AFs to do
the mapping for me.
 
> 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.

I'm not sure what you mean by that. Of course you need an AF-smart
processor to use them just as you need an XSL processor to use XSL.

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

XLL *is* an architecture. If you understand XLL then you understand
architectures. Other concepts are just more subtle variations on the
same concept.

The XLL standard defines some elements that describe an "interface". You
can declare that elements conform to that interface through an
attribute. An XLL-smart processor ignores the GI and works with the
element through the interface -- as if it were really an instance of the
element type defined in the XLL standard. That's an architecture. The
more subtle variations allow mapping attributes to elements and vice
versa and other things like that.
 
 Paul Prescod

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)