[
Lists Home |
Date Index |
Thread Index
]
> You can't ignore new elements and attributes like that.
> Sometimes, it can't
> be very wrong to do so (see my crappy example with the 'just-kidding'
> attribute). Knowing if you can safely ignore elements and
> attributes can be
> done at design time (after all, nobody forces you to send
> bleeding edge
> documents to legacy code), or try to enforce this in the
> runtime. But the
> general rule "ignore new elements" is a dangerous one, even
> if it perfectly
> suits HTML.
Ignore may be too strong a word here. I would expect unknown attributes and
elements to be handled in a "store and forward" manner. If it turns out that
a new version of the document includes new elements and attributes that are
absolutely essential to the correct processing of that document, then you're
stuck having to upgrade or modify your application anyway.
> >Another is whether the xml (the data) can say how it is
> supposed to be
> >processed:
> >
> >>It is about being able to
> >> mix some new code that uses the new document structure with
> >some old code
> >> that use the old document structure.
> >>
> >
> >At face value, this seems to ask that a document say how
> (parts of ) it
> >should be processed, perhaps with the help of a schema.
> That's a tall
> >order. I think the best that could be done in most cases is
> >for a document
> >to point to some other document that would contain some
> >description of the
> >intended processing. If the data language (like XML)
> >supported doing that,
> >it certainly could be said to be "extensible", and I think
> >that such could
> >be done in XML (to the extent, anyway, that you can describe
> process by
> >data).
I was wondering out loud today about the feasibility of using Ant[1] to
describe workflows. Why not? Building an application from components is
conceptually no different from building anything else from components. It
may not turn out to be the best approach, but it's certainly worth
exploring.
>
> I don't want the data to describe how it can be processed !
> I'm not crazy
> enough to hope that this can be easily done...
But what of appInfo annotations in XML Schema?
> I just want the schema to describe itself relatevily to
> another already
> known schema, and dynamically provide compatibility rules to legacy
> application, so that they can read data in extended schemata
> as if they were
> in the former schema, or forbid any usage of the document if
> it would be
> harmful. Those compatibility rules could be expressed in
> various ways, from
> views (à la AF), transformations, or a type system with
> inheritance and
> polymorphism, I don't know which is the best. What I notice
> however is that
> OOP provides solutions for extensibility, so that it may be
> interesting to
> have a close look at extensibility patterns in OOP before
> trying to solve
> the problem in XML.
>
> >So I don't see the issue of processing after a change to the
> >design as being
> >any instrinsic barrier to extensibility.
>
> It is not a barrier, it is a requirement...
>
> >It's only that the
> >extensibility
> >would be achieved in a different way from what many people are
> >used to. But
> >heck, if you want the old way, you can already serialize java
> >objects or
> >lisp code.
>
> I don't understand what you mean, here. We are asking
> ourselves what the 'X'
> in XML is for. Obviously, there is a lack of guidelines and processing
> models to achieve extensibility. Why should this
> extensibility be radically
> different from what we have in, say, ASN.1 (I'm not an
> expert, but it seems
> a common practice to have some "reserved" conditional blocks
> to provide
> extension points, that is to say extensions are foreseen when defining
> structures, they are not inserted a posteriori) ? What is the
> "old way"
> you're talking about ? Is it OOP ?
>
> >We were served well by going to more datacentric approaches in
> >the database
> >world - a relational database does not say how its tables and
> >data elements
> >are to be processed once they are retrieved. That's because
> >data (and its
> >design) is usually more stable over a long time than the
> >processing needs.
> >An example is being asked for new report types from old data.
> >Focusing more
> >on the data aspect (the markup approach) is fully in line with
> >this trend.
> >But it may be less "efficient" than using carefully crafted
> >procedural or
> >object code, when you think about any one processing run.
>
> That's an interesting point. When does data becomes code ? Is type
> information a piece of data, or a piece of code ? Should we fear types
> because they are bound to code, so they are unstable, or use them as a
> simple piece of meta-data ?
Maybe code should describe its data model. Why, for example, can't we we
declare a data model in Java and then hang classes off of it? Actually, you
could assume most of the accessor/mutator methods (wouldn't it be nice not
having to write those silly things)?
Is melding data models with class methods still too radical a concept? (I'm
sure someone's doing this already; maybe somebody's got the links?)
[1]http://jakarta.apache.org/ant/index.html
|
