Lists Home |
Date Index |
You seem to be implying that there is a magical quantity of XML that makes
it the best choice for certain types of purposes in certain types of
software architectures, and that there is a separate set of features for
information interchange (like representing a number as a number). Since
these are mutually incompatible, we need to decide which one we want.
In fact, the two are highly complementary! So much so that the whole is more
than the sum of its parts. Being able to do all the cool XML stuff (like
opening up a document, changing a number -- represented as text -- and
saving it again) while still having access to what the data really is (a
number is a number is a number) is what makes XML exciting in the first
place. Believe me, it wouldn't be a household name by now if it were just
SGML without SHORTTAG, LINK and CONCUR...
That said, you led me down the garden path with this PSVI stuff. My
understanding of the PSVI (very shaky, I admit) is that it is an abstract
formalism for representing an instance with its associated schema. Now I am
starting to understand that people actually want to serialize this as XML.
Now *that* definitely strikes me as a really bad idea.
But like someone said, don't throw the baby out with the bathwater. Schemas
are great. I have 0% doubt of that. Your problem is with the W3C process,
which appears to reward complexity while providing no incentive to keep
things simple. It's no surprise that we are building a bigger and bigger
mess of overgrown incomprehensible specs. Hey, it almost reminds me of...
SGML! Plus ca change...
> -----Original Message-----
> From: Simon St.Laurent [mailto:email@example.com]
> Sent: Thursday, May 09, 2002 8:29 PM
> To: Matthew Gertner
> Cc: firstname.lastname@example.org
> Subject: RE: [xml-dev] PSVI formalization
> I think we hit a key point here.
> On Thu, 2002-05-09 at 14:06, Matthew Gertner wrote:
> > > XML is a wonderful foundation for building certain kinds of
> > > information
> > > interchange systems, and a key tool for making it clear that
> > > information
> > > interchange is in fact possible. XML is not an ideal tool for
> > > exchanging all kinds of information, however. The
> metadata costs of
> > > working with a text format spiral rapidly as more complex
> types than
> > > element structures and attribute annotations are applied.
> > Who is talking about adding more complex types than
> elements and attributes?
> You are!
> > I thought we were just talking about defining the datatype
> of attribute
> > value and element leaf nodes more precisely than simply
> saying that they are
> > "PCDATA".
> And that's precisely where we diverge. XML 1.0 types use markup to
> identify structures in content. For example there may be
> information of
> type "quantity" that gets marked up as a "quantity" element. The
> definition of such things is notably called an "element type
> You're unhappy with the meager information these types
> provide, and want
> to pile on an extra layer of metadata that connects the element name
> "quantity" to something else - an integer, most likely.
> From my perspective, you're crossing a line there. While integers
> aren't particularly harmful in and of themselves, that's the leading
> point of a much much larger wedge. As that wedge moves
> deeper (see for
> example, XQuery/XPath) what was once a quantity is now an integer,
> perhaps constrained with min and max values, perhaps given
> another name
> to identify it as a particular type of integer.
> Once you have that much metadata about "quantity" you can do an awful
> lot of things you couldn't do when "quantity" was a textual type
> identifer applied to text. You can optimize the
> representation of that
> integer - which is what I've proposed - and you skip an awful lot of
> intermediate processing to reach that number.
> If all you really want is the number, why monkey around with
> text? You
> can still mix your numbers with text if you want - storing text in
> optimized binary formats is hardly a new idea - and you can do new
> things like build editors which have a much more direct connection to
> the information.
> The more the XML world tries to accomodate a programmer's view of
> information, the more I think we ought to just hand them
> that, and take
> it seriously. XML's broken down some important walls. There
> are walls
> ahead where I don't think it will be nearly as effective.
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!