[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent <simonstl@simonstl.com> writes:
> >
> >That is currently true, but in my other response to this
> thread I sort
> >of point out that this may be less and less true going
> forward. If you
> >want to have any half way decent treatment of your XML (say
> even within
> >your application) you may need a schema just to tell a parser how to
> >optimally parse your XML. This schema may come about after
> the fact,
> >but by the time you get to doing data exchange it should be hanging
> >around. Certainly, it seems an unreasonable expectation that one can
> >have much in the way of automated (or efficient manual) generalized
> >mappings without a schema (or equivalent metadata) on both
> sides of the
> >fence.
>
> That's assuming that your application is expected to know
> everything about incoming data up-front. There are plenty of
> cases where that isn't necessarily true. Stylesheets and
> similar mechanisms may provide information outside of a
> schema context, and human intervention may be a very
> reasonable expectation in many cases. Automation may create
> as many problems as it solves.
>
Sure, if all you know is that you use
document/foo[3]/bar[@blah='gunk']/@price
to get the value you shove into column 12 of table 87 then good luck. My
point is that if you expect any of this to work automatically then you're
going to have to be willing to do the work of getting a real schemas. Today
you have the XSLT++ produced by Frank in IT that spits out your spread
sheet. Tomorrow, maybe, you'll need the xsd++ that you feed into the magic
application that then spits out your spread sheet...
|
