Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: AFs and the DPH (Was Animal Friends, etc.)
 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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
