Cart
[Home] [By Thread] [By Date] [Recent Entries]
* Lars Marius Garshol | | They can do slightly more, but not much. They can leave out | elements, turn elements into attributes, and vice versa. There are | also some things relating to defaulting etc. * Ronald Bourret | | How useful is that in the real world? That is, if company A defines | one format for invoices and company B defines another format, what | are the chances that these are (hierarchically) similar enough that | I can define AFs to process them as a single format? My gut reaction | is that this is unlikely. Frankly, so is mine. The consensus in the SGML community seems to have been that you can only map between DTDs if they were designed for it, which they may well be, for example within a large organization where different departments have different needs. I think, however, that the real utility of AFs lies in very general applications like XInclude, XBase, and XLink. In XML you can have element type names in Yi, allowing villagers in southern China to have XML vocabularies in their native language, but current W3C practice requires certain of their element types to have English names (and awkward ones at that) in order to be interoperable. How much sense does that make? So the W3C family of specifications does need something *like* AFs, if not necessarily AFs as they are known from ISO 10744. In fact, I think the specification mechanism from ISO 10744 should be abandoned. AFs are, at heart, a subtyping mechanism for element/attribute types with attached processing semantics. It may well be that the politically and technically most feasible solution is to adapt the idea of AFs in the form of an extension to the subtyping mechanism in XML Schema. Of course, as long as many W3C people involuntarily make the sign of the cross whenever they hear the term 'architectural forms' chances are not very good. -- Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net > ISO SC34/WG3, OASIS GeoLang TC <URL: http://www.garshol.priv.no >
|
