Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Tue, 01 Apr 2003 09:48:59 +0100, Sean McGrath <sean.mcgrath@p...> wrote: [Checking very carefully to see if this is one of Sean's famous April Fool jokes ... hmm, no that's another thread] > Correctness or input fidelity - pick one - you cannot have both. > > This is at the core of why I've always argued that we *do* need a data > model for XML and we *do* need something like > common XML because I want my processing to be both correct *and* non- > lossy (high input fidelity). > > Is that too much to ask? Let me make sure I understand ... we need a definitive data model so that one can work with the normalized information in an XML document irrespective of whatever "syntax sugar" was used to represent the information, and we need something like Common XML to define a canonical serialization of the data model that can will not lose fidelity through successive parse / serialization stages? I agree. It sounds like existing data models don't quite do the job because they don't (except for the DOM data model, which has its own problems) let one keep unexpanded entity references around. Likewise Common XML as sml-dev defined it doesn't include entity definitions and references. I strongly agree if we're saying that XML (or some successor) needs a) to treat the syntax and data model as two halves of the same whole; b) to *conceptually* handle "syntax sugar" in a preprocessing phase where CDATA sections are handled, whitespace normalized, quotes standardized, [entities expanded ???], comments stripped out, [PI's stripped out???], etc.; c) the actual core grammar is based on the "Common XML" so text operations on the common/canonical syntax can be correct and non-lossy; d) alternate serializations of the data model are acknowledged as "legal" insofar as they reliably and losslessly round trip with the common/canonical syntax; e) additional information such as that introduced by schemas and other datatyping schemes is another layer on top of all this. That lets XML be text for text processing people and Desperate Perl/Python Hackers, and XML be data for data processing people, sharing common technologies where appropriate but adding different layers for specialized needs where appropriate.
|
