An inquiry into the nature of XML and how it orients our perception of information

[Roger Costello]

Hi Folks,

I oftentimes hear of people creating XML in an Object Oriented (OO) form, i.e., as classes and subclasses, or of people creating XML in a relational database form, i.e., as tables with rows and columns. I wonder if such forms are appropriate for XML? Does OO serve the same purpose as XML? Do relational tables serve the same purpose as XML?

Yesterday Philippe Poulard expressed a similar sentiment:

    I'm not sure that this OO paradigm can be applied
    in XML: a class is defined by its unordered members that
    a subclass can simply override, whereas the sequential
    nature of XML doesn't allow overriding only a given part
    of a content model.

    With ASL, I didn't try to adopt at any cost a feature that
    doesn't fit well in XML technologies, I'd rather tried to
    think different.

Lately I have been reading a couple of books [1][2] that have shaped my thinking on this subject. [1] asserts that the "form" in which information is expressed influences "what" can be expressed. Here are a few passages from the book:

    We experience the world through various lenses: speech,
    the printed word, the television, and others.

    Each form classifies the world for us, sequences it, frames
    it, enlarges it, reduces it, and colors it.

    The form in which ideas are expressed affects what those
    ideas will be.

    Each form makes possible a unique mode of discourse by
    providing a new orientation for thought and for expression.

In the computer information world there are various lenses: relational databases, XML documents, OO models, and others. Each form classifies, sequences, frames, reduces, enlarges, and colors our view of information. Each form orients our thought.

If you accept that a relational/tabular form orients ones thinking a certain way and that OO orients ones thinking in another way, then it appropriate to inquire whether such forms are suitable for XML. Must not an XML document orient ones thinking in a way that is harmonious with the XML form? From [2]:

    The Parthenon did not serve the same purpose as its
    wooden ancestor.

    ...the structure of a building is the key to its beauty;
    ...new methods of construction demand new forms

What are the consequences of constructing XML documents as a collection of classes and subclasses, or as tabular rows and columns? Do we destroy the beauty of XML? Is the lens provided by XML distorted? XML orients our thought. In what ways?


/Roger

[1] "Amusing Ourselves to Death" by Neil Postman.
[2] "The Fountainhead" by Ayn Rand.
_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Olivier Rossel]

May I mention the fact that XML represents trees, whereas a OO
structure is a graph?

Sorry, my RDF lens makes me see all the world as graphs :-P

On Fri, Nov 20, 2009 at 1:16 PM, Costello, Roger L. <costello@...> wrote:

>
> Hi Folks,
>
> I oftentimes hear of people creating XML in an Object Oriented (OO) form, i.e., as classes and subclasses, or of people creating XML in a relational database form, i.e., as tables with rows and columns. I wonder if such forms are appropriate for XML? Does OO serve the same purpose as XML? Do relational tables serve the same purpose as XML?
>
> Yesterday Philippe Poulard expressed a similar sentiment:
>
>    I'm not sure that this OO paradigm can be applied
>    in XML: a class is defined by its unordered members that
>    a subclass can simply override, whereas the sequential
>    nature of XML doesn't allow overriding only a given part
>    of a content model.
>
>    With ASL, I didn't try to adopt at any cost a feature that
>    doesn't fit well in XML technologies, I'd rather tried to
>    think different.
>
> Lately I have been reading a couple of books [1][2] that have shaped my thinking on this subject. [1] asserts that the "form" in which information is expressed influences "what" can be expressed. Here are a few passages from the book:
>
>    We experience the world through various lenses: speech,
>    the printed word, the television, and others.
>
>    Each form classifies the world for us, sequences it, frames
>    it, enlarges it, reduces it, and colors it.
>
>    The form in which ideas are expressed affects what those
>    ideas will be.
>
>    Each form makes possible a unique mode of discourse by
>    providing a new orientation for thought and for expression.
>
> In the computer information world there are various lenses: relational databases, XML documents, OO models, and others. Each form classifies, sequences, frames, reduces, enlarges, and colors our view of information. Each form orients our thought.
>
> If you accept that a relational/tabular form orients ones thinking a certain way and that OO orients ones thinking in another way, then it appropriate to inquire whether such forms are suitable for XML. Must not an XML document orient ones thinking in a way that is harmonious with the XML form? From [2]:
>
>    The Parthenon did not serve the same purpose as its
>    wooden ancestor.
>
>    ...the structure of a building is the key to its beauty;
>    ...new methods of construction demand new forms
>
> What are the consequences of constructing XML documents as a collection of classes and subclasses, or as tabular rows and columns? Do we destroy the beauty of XML? Is the lens provided by XML distorted? XML orients our thought. In what ways?
>
>
> /Roger
>
> [1] "Amusing Ourselves to Death" by Neil Postman.
> [2] "The Fountainhead" by Ayn Rand.
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@...
> subscribe: xml-dev-subscribe@...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Peter Hunsberger]

On Fri, Nov 20, 2009 at 6:16 AM, Costello, Roger L. <costello@...> wrote:
>
> What are the consequences of constructing XML documents
> as a collection of classes and subclasses, or as tabular rows
> and columns? Do we destroy the beauty of XML? Is the lens
> provided by XML distorted? XML orients our thought. In what ways?
>

As Olivier says, all data relationships fall into graphs: a data model
is a data model is a data model.  Doesn't mean the people doing it are
doing it in the optimal way for the problem domain at hand, but this
isn't a case of modelling XML vs modelling something else (OO or
relational, or whatever). The problem is how to optimize the graph
traversal for the given problem domain.  Sometimes that means thinking
in terms of objects, sometimes in terms of set relationships, but
ultimately those are short hand ways of talking about some best
practices for graph traversal. Now, if you do find a way to always get
the optimal graph traversal for any given problem domain you've
essentially solved all the problems of computer science.  IOW, there's
still lots of room for experimentation on what models work best in
what situations...

--
Peter Hunsberger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Mukul Gandhi]

Hi Roger,

On Fri, Nov 20, 2009 at 5:46 PM, Costello, Roger L. <costello@...> wrote:
> I oftentimes hear of people creating XML in an Object Oriented (OO) form, i.e., as classes and subclasses, or of people creating XML in a relational database form, i.e., as tables with rows and columns. I wonder if such forms are appropriate for XML? Does OO serve the same purpose as XML? Do relational tables serve the same purpose as XML?

I personally think, it's quite challanging to design (looks like too
much of an effort to me, for end user applications) an object oriented
system (let's say object's structure -- attribute and method
instances) modeled as XML document (instead we should use OO languages
for this :)). But certainly we write XSD Schemas, in OO fashion. I
would say, we sometimes design a particular domain type system, in OO
fashion. But I can't imagine, that usual real world XML instances can
easily be object oriented (I have not seen such an application design
commonly).

But ofcouse, we have systems which serialize OO system's, object state to XML.

> What are the consequences of constructing XML documents as a collection of classes and subclasses, or as tabular rows and columns?

Using XML documents to depict object state, and the user doing an
application design for this, looks like a big effort to me. I am not
sure, if such a design should be preferred. I have not commonly seen
this kind of program design. Some programming infrastructures (like
java for example), provide APIs to serialize object state, to XML (but
that's an infrastructure service, and not an application design).

Imagining XML documents, as tabular rows and columns I think, is yet
another application data model (and I think, it's used much in
application design). Of course, I think there are many other XML
instance models possible (depicted by so many kinds of XML Schema's,
that already exist, and those that are yet to be written).

> Do we destroy the beauty of XML?

I don't think so. If we make use of XML to model an OO instance, I
think that would just be another use of XML :)



--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Kurt Cagle-2]

Roger,

I think that the form of the modeling expression language has a huge impact upon the approach that one takes in dealing with the world. I have a good, real world example - I was recently hired to develop documentation for Mozilla's JetPack interfaces. The development team, for the most part, are people who come from a background that mixes C++ with JavaScript - developers who are agile, facile with object models, and generally quite bright. Most of their documentation system is built on a Mediawiki engine, with DekiWiki support integrated into it. Most of their documentation was consequently created in a fairly ad hoc manner, based upon copying templates and modifying them - essentially a form of cut and post. This has meant that their documentation was fairly labour intensive to create, and hence comparatively expensive.

After having spent the last several years immersed in XML pipelines, XQuery and XSLT transformations on the other hand, I came into it with the realization that if they could control the input model and run it through a production pipeline, so long as the input model was simple and familiar they could actually maintain things such as document APIs with considerably less effort and far less chance of document corruption or transcription errors, while at the same time providing all of the necessary metadata and semantic infrastructure to make the documentation much more like applications than passive text. The final form I came up with for the input model was something that looked vaguely JSONic, in great part because most web browser devs seem to have an almost pathological reaction to anything even hinting at pointy brackets.

Yet the key to all of this really came from the XML background - the devs were used to dealing with dynamic object models that did things, rather than working with declarative, functional pipelines and languages. To most JavaScript developers, a web page is a collection of objects, to most XML developers, a web page is a fairly uninteresting XML document that's either the input to or (more likely) the end state of a series of pure functional transformations. So yes, I think that one's "native" language has a huge impact upon your perceptions of how to solve a problem, for better or worse.

Kurt Cagle
Managing Editor
http://xmlToday.org

On Fri, Nov 20, 2009 at 4:16 AM, Costello, Roger L. <costello@...> wrote:

Hi Folks,

I oftentimes hear of people creating XML in an Object Oriented (OO) form, i.e., as classes and subclasses, or of people creating XML in a relational database form, i.e., as tables with rows and columns. I wonder if such forms are appropriate for XML? Does OO serve the same purpose as XML? Do relational tables serve the same purpose as XML?

Yesterday Philippe Poulard expressed a similar sentiment:

   I'm not sure that this OO paradigm can be applied
   in XML: a class is defined by its unordered members that
   a subclass can simply override, whereas the sequential
   nature of XML doesn't allow overriding only a given part
   of a content model.

   With ASL, I didn't try to adopt at any cost a feature that
   doesn't fit well in XML technologies, I'd rather tried to
   think different.

Lately I have been reading a couple of books [1][2] that have shaped my thinking on this subject. [1] asserts that the "form" in which information is expressed influences "what" can be expressed. Here are a few passages from the book:

   We experience the world through various lenses: speech,
   the printed word, the television, and others.

   Each form classifies the world for us, sequences it, frames
   it, enlarges it, reduces it, and colors it.

   The form in which ideas are expressed affects what those
   ideas will be.

   Each form makes possible a unique mode of discourse by
   providing a new orientation for thought and for expression.

In the computer information world there are various lenses: relational databases, XML documents, OO models, and others. Each form classifies, sequences, frames, reduces, enlarges, and colors our view of information. Each form orients our thought.

If you accept that a relational/tabular form orients ones thinking a certain way and that OO orients ones thinking in another way, then it appropriate to inquire whether such forms are suitable for XML. Must not an XML document orient ones thinking in a way that is harmonious with the XML form? From [2]:

   The Parthenon did not serve the same purpose as its
   wooden ancestor.

   ...the structure of a building is the key to its beauty;
   ...new methods of construction demand new forms

What are the consequences of constructing XML documents as a collection of classes and subclasses, or as tabular rows and columns? Do we destroy the beauty of XML? Is the lens provided by XML distorted? XML orients our thought. In what ways?


/Roger

[1] "Amusing Ourselves to Death" by Neil Postman.
[2] "The Fountainhead" by Ayn Rand.
_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Rick Jelliffe]

>
> Hi Folks,
>
> I oftentimes hear of people creating XML in an Object Oriented (OO) form,
> i.e., as classes and subclasses, or of people creating XML in a relational
> database form, i.e., as tables with rows and columns.

The use of classes and subclasses is characteristic but not definitive of
an object-oriented system. An object-oriented system is merely one where
all the characteristics of a thing (typically methods and fields) are
bundled, and where most or all things are objects.

Object-oriented systems almost always have classes, ever since the days of
Simula, to be sure. But it is possible to have an object-oriented design
in a non-class-based language such as C, sticking to a design pattern
where each struct has function pointers for accessing the data. (And a
class-based language is not necessarily an inheritance-based one either:
it could use prototyping, where the class object is copied.)

The other angle is that modern inheritance- oriented systems have moved
away from simple classes with simple inheritance to partial classes with
multiple inheritance and mixins: Java's interfaces and Scala's traits for
example.

So I don't know that people actually are "creating XML in an OO form",
speaking strictly.  I don't know that this changes any details of Roger's
question, but it does change the kinds of connections we might make.

Considering objects-oriented to refer to a methodology of bundling, I
would say that XML is completely non-object-oriented in relation to
bundling methods with data, and quite object-oriented in relation to
bundling related data together.

 I wonder if such
> forms are appropriate for XML? Does OO serve the same purpose as XML? Do
> relational tables serve the same purpose as XML?

I think there are a few different cases: perhaps one big distinction might
be whether you are wanting to expose the Java (for example) class system,
or hide it.

I really like the SwiXML XML language. It is a little facade above Java
Swing, where the Java Swing objects are created and connected by
interpreting the XML element names using reflection. So it is a very thin
layer. It is useful because many of the methods in a Swing objects are
visual characteristics that get set on initialization (and perhaps not
afterwards): so it is trivial to call a setter based on an attribute name.
In other words, most of the methods are setters which return void, rather
than functions which return some value.

So this kind of complex structure, which is instantiated all at the same
time, and whose interaction is largely either by setters properties
(rather than getters) then by listeners, seems very amenable to an XML
facade on top of the pre-existing API.

But there is no requirement to model the Java inheritance using XML, and
certainly not with XSD types. In fact, using the facade frees you from
that complexity.

Cheers
Rick Jelliffe

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Tim Bray]

On 2009-11-20, at 10:56 PM, rjelliffe@... wrote:

> The use of classes and subclasses is characteristic but not definitive of
> an object-oriented system. An object-oriented system is merely one where
> all the characteristics of a thing (typically methods and fields) are
> bundled, and where most or all things are objects.

Ever since Day 0, I've been uncomfortable with the notion that there's anything O-O about XML.  It seems to me at a pretty deep level that O-O is about hiding and encapsulation; an object is a thing that can do some things on demand, don't bother your pretty little head about how it's done.  

It seems to me like XML is oriented exactly 180° in the opposite direction: Here's the data, here are some labels for the data, here are some ordering and containment relationships, you're free to do whatever you want with it.  That's a good thing and (I've always the big win) - the provider doesn't constrain what the receiver does.  -Tim

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Michael Sokolov-2]

> From: Tim.Bray@... [mailto:Tim.Bray@...] >
> Ever since Day 0, I've been uncomfortable with the notion
> that there's anything O-O about XML.  

It makes me uncomfortable too, but it's sometimes the case that you need to
serialize your objects, and in such a case XML is a much better fit than
(say) tab-delimited text files.  The converse happens too - you sometimes
need to present your XML as an object, say to an application presentation
layer that has been built around the assumption that all data is objects.
The current XSLT Forms and XQuery application builders are trying to avoid
that, but I wonder if they will ever really supplant Java-based application
frameworks.

Where it really seems to go off the rails though is when people finding
themselves in these awkward situations decide they need a completely
universal top-to-bottom equivalence between XML Document and Object in an
attempt to magically make the impedance mismatch disappear.

-Mike


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Liam R E Quin-3]

On Fri, Nov 20, 2009 at 01:23:26PM +0100, Olivier Rossel wrote:
> May I mention the fact that XML represents trees, whereas a OO
> structure is a graph?
>
> Sorry, my RDF lens makes me see all the world as graphs :-P

Your RDF lens is obscurig the fact that XML documents, in the
most general cases, represent graphs, not trees :-)

(consider entities that can appear multiple times and have
multiple parents, sa well as id/idref relationships, for
example)

Liam


--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Liam R E Quin-3]

On Sat, Nov 21, 2009 at 11:49:03AM -0800, Tim Bray wrote:
> It seems to me at a pretty deep level that O-O is
> about hiding and encapsulation; an object is a thing that can do some things
> on demand, don't bother your pretty little head about how it's done.  
>
> It seems to me like XML is oriented exactly 180? in the opposite direction:
> Here's the data, here are some labels for the data, here are some ordering
> and containment relationships, you're free to do whatever you want with it.

+1

> That's a good thing and (I've always the big win) - the provider doesn't
> constrain what the receiver does.  -Tim

Yup, agreed 100% - it's why you can't speak of an XML document as
a function, but, rather, an XML processor is a function that takes
one or more XML documents as inputs...

The semantics in XML are extrinsic, not intrinsic.

Liam


--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Len Bullard]

Also agree.  We tried it with markup a couple of times.  It's data. Full
stop.

len


From: Liam Quin [mailto:liam@...]

On Sat, Nov 21, 2009 at 11:49:03AM -0800, Tim Bray wrote:
> It seems to me at a pretty deep level that O-O is
> about hiding and encapsulation; an object is a thing that can do some
things
> on demand, don't bother your pretty little head about how it's done.  
>
> It seems to me like XML is oriented exactly 180? in the opposite
direction:
> Here's the data, here are some labels for the data, here are some ordering
> and containment relationships, you're free to do whatever you want with
it.

+1

> That's a good thing and (I've always the big win) - the provider doesn't
> constrain what the receiver does.  -Tim

Yup, agreed 100% - it's why you can't speak of an XML document as
a function, but, rather, an XML processor is a function that takes
one or more XML documents as inputs...

The semantics in XML are extrinsic, not intrinsic.

Liam



_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Mukul Gandhi]

On Sun, Nov 22, 2009 at 10:15 AM, Len Bullard <cbullard@...> wrote:
> Also agree.  We tried it with markup a couple of times.  It's data. Full
> stop.

Are you saying, an XML document is always data? For example, an XML
format can be a XSLT stylesheet, XSD Schema, or say WSDL files, in
which case XML can be say programs, which can be executed.


--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Peter Hunsberger]

On Sat, Nov 21, 2009 at 10:54 PM, Mukul Gandhi <gandhi.mukul@...> wrote:
> On Sun, Nov 22, 2009 at 10:15 AM, Len Bullard <cbullard@...> wrote:
>> Also agree.  We tried it with markup a couple of times.  It's data. Full
>> stop.
>
> Are you saying, an XML document is always data?

It's always data. Not that tells us anything.

> For example, an XML
> format can be a XSLT stylesheet, XSD Schema, or say WSDL files, in
> which case XML can be say programs, which can be executed.

Yes, one mans data, is another persons metadata , is another persons
programming language...

--
Peter Hunsberger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Mukul Gandhi]

On Sun, Nov 22, 2009 at 10:35 AM, Peter Hunsberger
<peter.hunsberger@...> wrote:
> It's always data. Not that tells us anything.

As I understand, that data means any *information* that can be
provided as input or is produced as output, to/from some computational
process. So data can be say a string "hello world" which can be
produced as output from a software program. Or say, a primitive value
10 which can for example represent a person's age and feed in as an
input to some software program. In case of XML, the data is labeled by
markup tags (say, <age>10</age>).

As I understand about XML, it is a markup language, using which we can
design either data (please see, how I describe data above), or say a
programming language (in which case, the XML markup cannot be
considered a data, but an executable program, say an XSLT program).

> Yes, one mans data, is another persons metadata , is another persons
> programming language...

I would not completely disagree to this. But contradicting a bit to
this, I'll never consider a XSLT program as data (an XSLT markup would
always be, a representation of executable program for me, conceptually
like say a java or C program).


--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Liam R E Quin-3]

On Sun, Nov 22, 2009 at 12:22:18PM +0530, Mukul Gandhi wrote:
> As I understand about XML, it is a markup language, using which we can
> design either data (please see, how I describe data above), or say a
> programming language (in which case, the XML markup cannot be
> considered a data, but an executable program, say an XSLT program).

If I write an XSLT stylesheet that takes an XSLT "program" as
input and makes an SVG visualisation of the calll graph,
the input XSLT stylesheet is treated as data.

Program and data are not mutually exclusive.

Liam

--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/ * http://www.fromoldbooks.org/

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Alain COUTHURES]

Mukul Gandhi a écrit :

Yes, one mans data, is another persons metadata , is another persons
programming language...
    

I would not completely disagree to this. But contradicting a bit to
this, I'll never consider a XSLT program as data (an XSLT markup would
always be, a representation of executable program for me, conceptually
like say a java or C program).
  

It's sometimes very useful to consider programs as data. For example, the make utility treats programs to be compiled and linked: it's a sort of "meta-program" with programs as data. Having an XML notation for programming language allows to process them as any XML data. What is a program or what is data is just a point of view: when a system receives a purchase order, it receives purchase data and the order to process it; in a sense, the purchase order is written in a very specific programming language that the server can understand. It's the same for an HTML page: <h1> can be interpreted as the data for header at level 1 or as an instruction to write a header at level 1.

Java or C languages don't benefit of an XML notation but it's mainly an human constraint: it's easier for developers to write instructions this way. Smart editors could interpret instructions to write them internally in XML while still render them as they are now. Analyze and generate instructions can then be very powerful.

If you look at instructions generated by yacc, you will find that C arrays of data are actually generated and that there is an engine to interpreted them. Is Java P-Code data or instructions ??? XML didn't create this but with XML is more and more obvious.

It's in developers culture to distinguish between data and instructions since assembling languages and it's easy to accept but it is not true for computers.

Best regards,

Alain Couthures
<agenceXML>
http://www.agencexml.com
Bordeaux, France

[Mukul Gandhi]

Thanks, Liam.

On Sun, Nov 22, 2009 at 12:57 PM, Liam Quin <liam@...> wrote:
> If I write an XSLT stylesheet that takes an XSLT "program" as
> input and makes an SVG visualisation of the calll graph,
> the input XSLT stylesheet is treated as data.

I agree. In this case, the input stylesheet was data (for the
stylesheet, which processed this input). I think, this could be true
for any programming language (or most of them). Say a Java program can
take as input another, Java program and produces something else (say,
a C/C++ output or whatever). As per your analogy, the input Java
program was a data in this case (and that's true :)).

What is wished to express was, that XSLT stylesheet is commonly
considered an executable entity (like, say a Java program for
example). XSLT is designed to be like that :) It's not a data
expression language (and incidentally, it uses an XML vocabulary, in
the XML namespace http://www.w3.org/1999/XSL/Transform).

> Program and data are not mutually exclusive.

Sorry for disagreeing, probably (not entirely, though). Theoretically
speaking, I might consider program and data as mutually exclusive. I
consider, programs as a set of instructions, which operate on some
input (which I think, as data), and then the program produces some
output (which could be data, or something else, say rendering a GUI).



--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Mukul Gandhi]

On Sun, Nov 22, 2009 at 12:59 PM, COUTHURES Alain
<alain.couthures@...> wrote:
> It's sometimes very useful to consider programs as data.

Yes, definitely. Liam gave a nice example (XSLT to SVG conversion),
which looks like a good use case for this view.

> For example, the make utility treats programs to be compiled and linked: it's a sort of
> "meta-program" with programs as data.

That's true. Thanks for a nice example.

> Having an XML notation for programming language allows to process them as any XML data.

I agree.

> What is a program or what is data is just a point of view:

I agree. But I wanted to express, that a programming language (like,
XSLT for example) would generally be considered a "program" or
something that can execute via a suitable engine. Considering program
as data are special cases (it's also true, that such examples are in
abundance, like the "make" utility example you gave, or an example
with Liam gave), and help us design systems for certain needs (like,
say make system or "XSLT to SVG" conversion systems).

> It's the same for an HTML page: <h1> can be interpreted as the
> data for header at level 1 or as an instruction to write a header at level

I agree, and also concur that it's somebody's perception, that what
could be data and what are programs.

> Java or C languages don't benefit of an XML notation but it's mainly an
> human constraint: it's easier for developers to write instructions this way.

I agree. Perhaps designing imperative programming languages, was
easier in java/C like syntax and being able to express imperative
facilities for such languages, and also allowing programmers to easily
program (or express easily) in these languages. Also it looks like,
that Java/C syntax can be perhaps less verbose than say an equivalent
XML vocabulary (but I guess, verboseness is not the only factor that
can decide in which format to express a software program. There could
be other factors like, the nature of the technology itself. It seems,
XML format is inherently functional, and trying to design an
imperative system in XML vocabulary would be perhaps putting too much
effort, to bridge the imperative-functional mismatch). I am not sure,
how easy (or convenient, and developing an implementation for it) it
is to design imperative languages using XML vocabulary. I have
commonly found, that languages expressed as XML vocabulary are
generally functional in nature.

> It's in developers culture to distinguish between data and instructions
> since assembling languages and it's easy to accept but it is not true for
> computers.

I agree :)



--
Regards,
Mukul Gandhi

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Peter Hunsberger]

On Sun, Nov 22, 2009 at 5:42 AM, Mukul Gandhi <gandhi.mukul@...> wrote:
> On Sun, Nov 22, 2009 at 12:59 PM, COUTHURES Alain
> <alain.couthures@...> wrote:
>
>> What is a program or what is data is just a point of view:
>
> I agree. But I wanted to express, that a programming language (like,
> XSLT for example) would generally be considered a "program" or
> something that can execute via a suitable engine. Considering program
> as data are special cases

It's the other way around.  Considering data and programs as two
separate things is an artificially contrived distinction.  It's maybe
useful for learning how to use some programming languages, but it
should be thrown away by the time you want to deal with anything in a
more general fashion.

The more semantics you have associated with a given piece of data the
more easily you can use it to instruct some other piece of data as to
what to do with it.  Programs that have restricted vocabularies put
more requirements on what they will use as input, but ultimately it's
all a matter of degree as to what data can be used as a program when
and where.  Ultimately, there is only the "machine" (virtual or real)
and it handles only one thing: call it what you will....

--
Peter Hunsberger

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@...
subscribe: xml-dev-subscribe@...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Kurt Cagle-2]

The semantics in XML are extrinsic, not intrinsic.

Liam,

I think that statement alone has a huge impact upon the way that people think about XML processing. The vast majority of programmers out there work upon the fundamental assumption that their semantics are fixed and immutable, beyond those that they specifically extend. Certainly, anybody who has adopted the Strousup OOP model feels this way ... type is intrinsic, objects, once created, maintain their own identity (even in the face of changes of state), and internal state is both protected and hidden. None of this is true with XML pipe processing. You can create some object-like behavior (especially if you are willing to lose declarativeness as a primary characteristic, which is unfortunate) in languages such as XQuery with XQUF support, but none of the pillars of OOP - polymorphism, inheritance, or encapsulation - are intrinsic to XML documents. Shifting to this view, however, requires that you step outside of your assumption that reality is complete and whole in and of itself and instead is simply a series of cleverly constructed sets, rebuilt meticulously every 10^-43 second.

-- Kurt