[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Stupid Question (was RE: XML doesn't dese rve it
I've read this document and found it quite interesting indeed. I believe much more in the first solution (extensibility by type inheritance) than in the second (extensibility using xsd:any), because there is a clear association between polymorphism in data (an extended book element can replace an old-style book element) and polymorphism in code, whereas there is not an easy processing model matching the xsd:any approach. Plus, xsd:any suffers from the non-determinism problem (at least in XML Schema, though it would not suffer this problem in RNG). But I find myself thinking again that in the first solution, obtaining PSVI at parse-time would be great, since it would enable to select the proper handler class depending on the type of the elements, then use those handler class through classic OOP polymorphism. It is pretty obvious to me that if data is typed, and the type model supports inheritance and polymorphism, then obtaining type information at runtime is a must, because it would allow us to use classic OOP design patterns based on polymorphism to develop programs that could gracefully sustain the extension of schemas. This would be done by having a mapping between types coming from the PSVI and handler classes. To allow an application written for a given schema to support the schema extension, I would just have to provide new handler classes inheriting the legacy handler classes, and add new entries to the types<->handler classes mapping (which would typically reside in a configuration file). I have no idea of what the handler classes would look like, but my first try at it would be a kind of application-specific DOM. The type mapping would build this application-specific DOM from a stream of SAX events or from a W3C DOM instance (since I think PSVI cannot be obtained in a first-pass parsing with SAX, the full document must be parsed first to allow the PSV to resolve some lookaheads). Methods would be provided to access any data of interest, but in an application-specific (not XML) way . Those methods would be overriden in extended handler classes. The result would be a basic XML-to-Object mapping, with the object either replacing the W3C DOM or just providing an application-specific view of it. What's interesting in this model is that the mapping can be dynamically extended without touching the source code of the application (just add handler classes and change the mapping file), yet the behaviour of the application remain consistent (since polymorphic calls to handlers help to maintain - or purposely break - schema compatibility). In fact it's so feasable that I just need a proper XML Parser / XML Schema validator supporting PSVI and I could have a try at implementing the rest. Does anyone knows about the availability of PSVI in Java based parsers ? I've read here that the Microsoft one provided correct PSVI, but I'd rather try this in Java (anyway, if nothing is available, I have yet to try writing serious programs with the C# thing, so...). Regards, Nicolas ----- Original Message ----- From: "Jeff Lowery" <jlowery@s...> To: "Jeff Lowery" <jlowery@s...>; "'Dare Obasanjo'" <dareo@m...>; <xml-dev@l...> Sent: Thursday, March 07, 2002 7:49 PM Subject: RE: Stupid Question (was RE: XML doesn't dese rve its "X".) > Spoke too soon. Looks like a lot is already covered on [1] under the title > "Extensible Content Models"; is that of the flavor you crave, Dare? > > > > > > ... What I'd like to see are examples and design > > > patterns that show how subtitution groups and abstract types > > > can be used to build polymorphic apps that adapt well to > > > schema evolution. > > > > I think that's an excellent suggestion for an addition to the > > Best Practices > > web site[1]. There's already some coverage there on Schema versioning > > (thanks, Priscilla); Schema robusting(?) would go > > hand-in-hand with that. I > > offer some thoughts on that subject in soon-to-be published book > > <?whoTooted?>, but an open discussion of tried and true > > approaches would > > certainly educate us all. > > > > [1] http://www.xfront.com/BestPracticesHomepage.html > > [2] http://www.manning.com/lowery/index.html > > > > ----------------------------------------------------------------- > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > > initiative of OASIS <http://www.oasis-open.org> > > > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > > > To subscribe or unsubscribe from this list use the subscription > > manager: <http://lists.xml.org/ob/adm.pl> > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> > >
|
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
|