OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] XML is text-only ... why?

Costello, Roger L. a écrit :
 > [xml-dev] XML is text-only ... why?

That depends on whether you are talking about the markup representation 
(which is definitively a text representation) or about the data model.

In the data model, it is said that instead of processing the litteral 
datas ("23"), an application could process the typed data (the integer 23)
XSLT 2.0 and XQuery are working like this, sometimes thanks to a type 
information given by a schema (xs:integer) and sometimes with implicit 
rules for converting "23" to 23.

The usual way to get it is :
XML -> parse -> validate -> augment -> data model
(the more often in a streaming mode)

An application sensible to PSVI will see the XML items, say an 
attribute, with its text value "23" and bound to it a typed data, say 
the xs:integer 23.

Now consider that the source of the data model is not an XML document 
(those represented with markups), but built by another software 
component ; you can bind in the PSVI other objects that are not 
derivative from text, instead you could bind some binary datas or 
whatever you want ; but what would be the text value ? something 
useless, say, the reference to the object bound to the node ; so, is XML 
still text ? At a high level, not really.

Is it usefull ? In my own experience where I applied this strange 
concept, yes : it is sometimes much more valuable to deal with the XML 
data model not necessary representable with markups than with pure 
textual XML datas :
-because you avoid cost round-trips between the markup representation 
and the data model
-because you can deal with binary objects (such as a JPG image) for 
which a markup representation is irrelevant (although you could get one 
with some base64 encoding, or an hex-to-digit representation)
-because you have to deal with a small amount of datas (and getting all 
the markup would be inefficient)

Example : say that you have the representation of some directory of your 
file system stored in an XML-friendly object ; you could operate on it 
like this :
$dir//*[ends-with(., 'xml')]
$dir//*[@io:size > 1024]

$dir is not represented with markups, you would have to browse the 
entire file system to get it whereas you operate locally on it.

I called this kind of objects X-operable objects (cross-operable 
objects), that is to say objects that are XML-friendly : you can apply 
XPath expressions on them, you can apply XUpdate-like operations on 
them, but they are not necessary representable with markup ; as it is 
still XML, XML is not text only.

All that stuff was presented at Extreme Markup Languages last month, and 
you'll find more infos here (the paper and the PDF presentation) :

And of course, it is implemented in RefleX !

Have the RefleX !


              (. .)
|      Philippe Poulard       |
        Have the RefleX !

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS