[
Lists Home |
Date Index |
Thread Index
]
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@scenicsoft.com>
To: "Jeff Lowery" <jlowery@scenicsoft.com>; "'Dare Obasanjo'"
<dareo@microsoft.com>; <xml-dev@lists.xml.org>
Sent: Thursday, March 07, 2002 7:49 PM
Subject: RE: [xml-dev] Stupid Question (was RE: [xml-dev] 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>
>
>
|
