[
Lists Home |
Date Index |
Thread Index
]
Total passionate disagreement. I can hardly think of any cases where
processing an XML document *doesn't* require some kind of datatype
information. Storing the document to disk or transferring it as text,
perhaps, but even when rendering a document in a browser you'll want to do
formatting (as some have pointed out), in which case you need to know about
the datatypes. IMO an XML document alone has about 10% of the value of a
document with its schema. Since there is the possibility of having a single,
canonical representation of the document semantics (specifically the
datatypes in this case) in the form of a schema, why on earth would we
reject this?
Can you explain how explicitly this "bloated type infrastructure" is
harmful, and what you can usefully do with an XML document without this
information? Is this a criticism of the notion of a schema in general, or of
XSD in particular?
Cheers,
Matt
> -----Original Message-----
> From: Simon St.Laurent [mailto:simonstl@simonstl.com]
> Sent: Tuesday, May 07, 2002 3:48 PM
> To: Matthew Gertner
> Cc: xml-dev@lists.xml.org
> Subject: working with text (was RE: [xml-dev] XPath 1.5?)
>
>
> On Tue, 2002-05-07 at 09:26, Matthew Gertner wrote:
> > Admittedly I am just restating the problem, but I am
> curious to know why you
> > are so convinced that the data in XML documents are strings
> that can be
> > translated into other data types when necessary, and not
> dates, number, etc.
> > that are serialized as strings when an XML document is instantiated.
>
> I think the problem is that XML itself is _only_ lexical
> representation,
> defining an approach to marking up textual representations of
> information with tags to create structure. There are no dates, except
> as you label them such.
>
> > The
> > counterargument, which strikes me as extremely compelling, is that
> > practically every environment *other* than an XML document
> would benefit
> > from explicit use of the underlying datatypes.
>
> True, but perhaps every other environment would benefit from a toolkit
> other than XML that had such datatypes more than XML itself
> will benefit
> from the imposition of such types.
>
> > This includes storage
> > engines, user interfaces (where formatting, localization
> and type/range
> > checking must occur), most popular programming languages, etc. I can
> > certainly say from my experience programming in Java and
> C++ that I would
> > prefer for a number to be a number and for a date to be a
> date, rather than
> > having to constantly convert back and forth.
>
> Provided that you use a consistent lexical and markup convention for
> your information, you can do that, with no need to impose a single
> lexical convention or a bloated type infrastructure on every user of
> XML.
>
> My experience programming in Java and my experience working with XML
> have led me to believe that each appropriate type (and lack of type)
> conventions for the style of information representation they provide.
>
> Programmers seemed to insist on the distinction between markup and
> programming languages in the 90s when HTML seemed an
> annoyance to them,
> but are a lot more eager to blur that line at present.
>
> --
> Simon St.Laurent
> Ring around the content, a pocket full of brackets
> Errors, errors, all fall down!
> http://simonstl.com
>
|
