[
Lists Home |
Date Index |
Thread Index
]
* 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 >
|
