[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML and embedded compound data types (was "Why XML data typin is har

• From: "Gabe Beged-Dov" <begeddov@j...>
• To: "Paul Prescod" <paul@p...>
• Date: Mon, 30 Nov 1998 11:38:59 -0800

>What is the "source data?" XML is a language description tool. It is not a
>database serialization tool. In many cases the "source data" is my head.
>XML happens to be useful as a database serialization tool because
>databases are simpler than the stuff I have in my head.

This seems to be one of the many dimensions along which people diverge in
their interpretation of "What is XML", i.e. human centric vs. data centric.
I have experienced enough of these philosophical discussions, both first
hand, and as an observer on this and other forums, to hope to steer towards
less turbulent waters.

>Just out of curiousity, here are some of the XML-related specs that fail
>according to your heuristic:
>
> * XPointer
> * XML Namespaces
> * XSL


My impression is that namespaces should be seen as part of the core syntax
of XML. The application should not need to parse namespace information out
of the data handed it by the processor.

It is true that XSL and XPointer bring their own parsing requirements to the
table. On the other hand, it seems that an attempt has been made, wherever
possible, to use the structural facilities of XML in lieu of other syntax.

My primary intent was to flag the fact that compound types should be
explicity decomposed when mapped to XML.  Michael Kay (and many others) have
brought up the concept of canonical representations as the interchange
format. Pragmatism argues for reusing existing canonical representations
such as ISO 8601.  In order for this to meet my "no parse" rule, it would
require a conforming processor, and internal representations like DOM, to
support all these compound types.

An alternative is to push it up a level, like many people have suggested,
but with the nuance that you strongly encourage/enforce that prescription
that no additional structure should be hidden in the document that requires
application parsing.

Gabe Beged-Dov
www.jfinity.com






xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Prev by Date: Default Namespace should be clearly documented and supported by specific <TAG> type
• Next by Date: Re: Why XML data typing is hard
• Previous by thread: Re: XML and embedded compound data types (was "Why XML data typin is hard")
• Next by thread: Default Namespace should be clearly documented and supported by specific <TAG> type
• Index(es):
  • Date
  • Thread