Cart
[Home] [By Thread] [By Date] [Recent Entries]
Didier PH Martin wrote: > This said, thanks for bringing the subject because, for me, "architectures" > are closer to "interface" like found in C++ base classes or Java interfaces. > And what is an interface after all? In its simplest form, we can say that it > is a contract that assure the client that, even if an implementation does > something totally differently than an other one, we still have the same way > to interact with all the implementations. So, for example, if I have a > particular document structure (all the elements have names totally different > than Hytime) an Hytime apps can still interact with my document structure. > Thus, the concept is similar to the notion of interface. Yes, this is I think the closest programming analog to document architectures. When an element in a document is mapped to some architectural element, you are saying "my element 'foo' conforms to the rules for architectural element 'bar', in addition to whatever else I might say a 'foo' is." That lets a user or processor of the document know something about the elements in it without having to know everything. I think that is analogous to saying "objects that implement the 'foo' interface must provide properties A, B, and C, implement methods D, E, and F, and accept messages G, H, and I". I like the interface analogy better than the "inheritance" analogy because it stresses the contract aspect of the relationship and does not imply any of the things that inheritance implies (which architectures do not provide, not being about program objects but about inert data elements). Cheers, E. 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
