Just Started XSL

[Lew]

Now that I'm almost finished reading my XML text, I need to invent a
project that will require three pages (or so) of code, to finish
training myself in the language. My idea was to write a numerical
integrator, matrix invertor and/or a curve plotting routine. XML's
liitations have killed every single one of my ideas, so perhaps you can
see why I'm unhappy with it.

Nope. You keep trying to make it do something it isn't even supposed to do,
then you blame XML. It's not XML's fault.

 

[Arved Sandstrom]

That won't help me teach myself XML.

Depends on what your goals are. You said you had some scientific
projects in mind, and unless the input data itself are in XML format
there is no point in trying to artificially jam it into the process.

If you want to learn XML at the same time, no harm done in devising an
XML schema for your input data, marking it up, and learning how to parse
it in your programming language of choice. The output of the parser can
be delivered directly to plotting routines, or processed further before
being plotted.

XML is fundamentally a markup language for data, including documents.
Yes, you'll run across XML usages, like XSLT, that push the envelope of
that definition, but 99 percent of the time XML files are simply encoded
textual data. XML files are an input to your actual programs just like
data from databases or flat files.

It strikes me that if you're getting this kind of flawed picture of XML
from this book then it can't be a particularly good one.

AHS

 

[Nik Coughlin]

Are you saying that XSLT is pixel addressable?

I have no idea what you mean by "pixel addressable". I presume you mean
that you want to draw things with XSLT.

XSLT is a transformation language for turning XML into something else. I
have no idea what you are transforming the XML to, but I presume that you
are using XML+XSLT in conjunction with a web browser, given the groups that
you are posting to.

If your XML contains some data from which you can extrapolate pixel data (x,
y, color presumably), you can transform that into SVG, which is an XML
format that describes graphics.

It describes vector graphics rather than raster graphics which is actually
better suited to your requirements but you can plot to it in a more pixel
based fashion if you so desire.

 

[Lew]

That won't help me teach myself XML.

Actually, it could. XML can no more serve as a programming language than can
a comma-separated values (CSV) file. It's a *data* format, not a programming
language. Using an actual programming language to process data in an XML
format is the way to learn XML.

 

[Lew]

I have no idea what you mean by "pixel addressable". I presume you mean
that you want to draw things with XSLT.

XSLT is a transformation language for turning XML into something else. I
have no idea what you are transforming the XML to, but I presume that
you are using XML+XSLT in conjunction with a web browser, given the
groups that you are posting to.

If your XML contains some data from which you can extrapolate pixel data
(x, y, color presumably), you can transform that into SVG, which is an
XML format that describes graphics.

It describes vector graphics rather than raster graphics which is
actually better suited to your requirements but you can plot to it in a
more pixel based fashion if you so desire.

Here's a made-up example:

<pixeladdressable>
<shape name="square" unit="pixel" >
<vertex x="0" y="0" />
<vertex x="0" y="100" />
<vertex x="100" y="100" />
<vertex x="100" y="0" />
</shape>
</pixeladdressable>

 

[Andy Dingley]

Sure it is.  The commands are ELEMENT, ATTLIST, ENTITY, NOTATION and a
couple of more that I don't feel like looking up.

They aren't _commands_. XML is no more a programming language than
HTML is.

 

[Andy Dingley]

XML can no more serve as a programming language than can
a comma-separated values (CSV) file.  It's a *data* format, not a programming
language.  

I'd (sometimes) even question that it's even that much. It's a format
certainly, but even reverse-engineering the XML-Infoset specification
onto something that was initially defined as a serialisation and a
parsing model but no more than that was an uphill task. You can
extract some "data" from XML documents, but not in a logically well-
defined fashion. Once you start to push the envelope of it, you'll
start to find serious holes in how to read this format and extract the
data from it.

The obvious contrast is RDF & RDF/XML. That's a well-defined data
model first that then had a serialisation defined for it.

 

[RedGrittyBrick]

I sure wish XML had mathematical data types and pixel adressability for
display. I've got some good project ideas, and I can't do them, because
they're scientific programming and display projects.

XML is ideally suited to this.

<?xml version="1.0"?>
<screen>
<pixel>
<location type="cartesian">
<x_coordinate>0</x_coordinate>
<y_coordinate>0</y_coordinate>
<location>
<attributes>
<color type="RGB" scale="255">
<red>0</red>
<green>0</green>
<blue>128</blue>
</color>
</attributes>
</pixel>
...
<pixel>
<location type="cartesian">
<x_coordinate>1680</x_coordinate>
<y_coordinate>1050</y_coordinate>
<location>
<attributes>
<color type="RGB" scale="255">
<red>33</red>
<green>17</green>
<blue>22</blue>
</color>
</attributes>
</pixel>
</screen>

 

[Lew]

I'd (sometimes) even question that it's even that much. It's a format
certainly, but even reverse-engineering the XML-Infoset specification
onto something that was initially defined as a serialisation and a
parsing model but no more than that was an uphill task. You can
extract some "data" from XML documents, but not in a logically well-
defined fashion. Once you start to push the envelope of it, you'll
start to find serious holes in how to read this format and extract the
data from it.

I've been using XML for over a decade and I disagree with your assessment.
"Uphill task"? The first time I used it, with a week's knowledge of it, I was
able to use it very effectively as a data format. In fact, it was so robust
and easy that it accelerated an EDI-to-database project by at least an order
of magnitude. I have yet to find any holes in how to read and extract from
XML, much less serious ones.

The obvious contrast is RDF & RDF/XML. That's a well-defined data
model first that then had a serialisation defined for it.

XML is general purpose and semantically void. It is possible to use it for
any number of "well-defined data models".

As for serialization, JAXB is another thing that just worked after a day or
two of my first exposure to it.

 

[Lew]

XML is ideally suited to this.

<?xml version="1.0"?>
<screen>
<pixel>
<location type="cartesian">
<x_coordinate>0</x_coordinate>
<y_coordinate>0</y_coordinate>
<location>
<attributes>
<color type="RGB" scale="255">
<red>0</red>
<green>0</green>
<blue>128</blue>
</color>
</attributes>
</pixel>
...

<scientific>
<constant name="gravitational constant" >
<unit>m^3 kg^-1 s^-2</unit>
<value>6.67428</value>
<error>+-0.00067</error>
<symbol>G</symbol>
</constant>
</scientific>

 

[Bluuuuuue Rajah]

I have no idea what you mean by "pixel addressable". I presume you
mean that you want to draw things with XSLT.

XSLT is a transformation language for turning XML into something else.
I have no idea what you are transforming the XML to, but I presume
that you are using XML+XSLT in conjunction with a web browser, given
the groups that you are posting to.

If your XML contains some data from which you can extrapolate pixel
data (x, y, color presumably), you can transform that into SVG, which
is an XML format that describes graphics.

Thank you! That's what I was looking for.

It describes vector graphics rather than raster graphics which is
actually better suited to your requirements but you can plot to it in
a more pixel based fashion if you so desire.

Each has its advantages and disadvantages. Are you saying that the SVG
vector graphics can't be tramsformed into raster graphics? Bmp files
are very similar to raster graphics, so maybe I could use that format.

Incidentally, will I be able to get the mathematical operations (+,-,
*,/) anywhere, that I'll need to generate data?

 

[Lew]

Incidentally, will I be able to get the mathematical operations (+,-,
*,/) anywhere, that I'll need to generate data?

Yes. You can get them from Java, for example.

 

[Andy Dingley]

I've been using XML for over a decade and I disagree with your assessment..
"Uphill task"?  The first time I used it, with a week's knowledge of it, I was
able to use it very effectively as a data format.  

That's typical. At the level of "a week's experience", you can get
your own data in and out. The fact that XML is so accessible for use
as a data format is one big reason why it was so popular, so quickly.

The problem starts when you don't just try to manipulate your own data
by example, but when you need to identify a formal model for everyone
to do so. XML is badly restricted here by what it's even possible to
do (trees not generalised graphs, the universe of discourse being
limited to the document itself, what support there is for ID / IDREF
is scant) but it's also difficult to define what it is that XML does
with high precision and formal robustness (read the early drafts of
XML-Infoset).

XML evolved from some uses of SGML, and SGML is a document format that
_doesn't_ define a related data format. XML had to have this added to
it later, and it wasn't a clean-cut task. Going back about 10 years
and reading debates with Jukka and Arjun Ray would show some of the
limitations, Arjun's questions in particular.

XML is general purpose and semantically void.  It is possible to use it for
any number of "well-defined data models".

We're inconsistent here in how we're using the term "data model" - the
usual problem of a technical discussion running out of dictionary
words. XML can certainly be used for any number of schemas (small S)
as can be defined by DTDs, XML Schema, Relax NG or informally. However
there also needs to be an underlying low-level model that is
consistent across all uses of XML (otherwise we can't interwork) and
this is where the problem is. It's not defined by the XML
specification, at the time the XML specification was written it wasn't
even defined anywhere. ad hoc assumption gets most projects up and
running internally, but it's not the same as a formal proof of
behaviour.

 

[Roy A.]

Whilst XML is used to represent several programming languages

XML is not used to represent any programming languages. That would not
be possible, kan you give a singele example? Ok, I know it is possible
to describe an programming language with sequent expressions, but that
can't be what you're refering to.

(including XSLT), I'd agree with you that it isn't itself.  However
XSLT certainly is.

XSLT, certainly is not a programming language. How did you get that
idea?

 

[Roy A.]

David Lamb skrev:

A sad commentary on current practice: I seem to recall a JavaLobby
article recently (say, within 6 mths) where somebody basically said XSLT
is dying out, and good riddance, because it requires people to learn a
"functional" mindset and procedural is all people are willing to use.

We know, Andy Dingley, that you're all about Microsoft or $MS, or
$mirosoft as you like to call them.

 

[Roy A.]

Andy Dingley skrev:

I'd (sometimes) even question that it's even that much.

How can you disagree with <[email protected]>? Are not xml as much
as a data format? And then I have to ask is an CSV file more as a data
format? Are you crazy, or do you just want to fine another way to
mention "Head First HTML with CSS & XHTML"?

It's a format
certainly, but even reverse-engineering

Reverse-engineering of an data format, what? Ok, I know you love
microsoft, so I suppose you expect reverse-engineering on data in any
format, like reverse enginering on data like passwords?

But how are an comma-separated values (CSV) file anyting better,or
are you just commeting because you can?

 

[Roy A.]

Andy Dingley skrev:

That's typical. At the level of "a week's experience", you can get
your own data in and out. The fact that XML is so accessible for use
as a data format is one big reason why it was so popular, so quickly.

Another reason is that microsoft supposably supports it.

The problem starts when you don't just try to manipulate your own data
by example, but when you need to identify a formal model for everyone
to do so. ....
XML is badly restricted here by what it's even possible to
do

XML can't do anything, it's a data format, you silly old bat.

(trees not generalised graphs, the universe of discourse being
limited to the document itself, what support there is for ID / IDREF
is scant) ....
but it's also difficult to define what it is that XML does
with high precision and formal robustness

It is not hard, it is defined in http://www.w3.org/TR/REC-xml/.

(read the early drafts of
XML-Infoset).

Yes, okay. But why?

XML evolved from some uses of SGML, and SGML is a document format that
_doesn't_ define a related data format.

That's right XML is defining data formats, not related data formats.

XML had to have this added to
it later, and it wasn't a clean-cut task. Going back about 10 years
and reading debates with Jukka and Arjun Ray would show some of the
limitations, Arjun's questions in particular.

That is right and that is the purpose.

and semantically void.  

"semantically void"? are you kidding. XML is semantically well defined
as an data foramat. Can you please explain what you mean?

It is possible to use it for

We're inconsistent here in how we're using the term "data model"

An "data model" is defined by ISO as "organization of data in an
database", so I don't see how your
definition could be that different. Most databases is relonation
databases, an an model of an relonation database is well known. Hell,
what type of databases are you talking about?

- the
usual problem of a technical discussion running out of dictionary
words.

So you're running out of words? Because, my dictionary is not.

XML can certainly be used for any number of schemas (small S)
as can be defined by DTDs, XML Schema, Relax NG or informally. ....
However
there also needs to be an underlying low-level model that is
consistent across all uses of XML (otherwise we can't interwork)

Why? We know how to interwork. It is spesified in an namespace.

and
this is where the problem is. It's not defined by the XML
specification,

Of course not, XML is defining the format and the definition of this
format, other things like what you are mention is defined in "XML
Information Set".

at the time the XML specification was written it wasn't
even defined anywhere.

So what?, They didn't know of this allready then? You're more crazy
than you sounds.

 

[Pherdnut]

XML is not used to represent any programming languages. That would not
be possible, kan you give a singele example?

XSLT is a programming language represented in XML.  Google easily turns up  
other examples, such as o:XML and MetaL.

[...]

(including XSLT), I'd agree with you that it isn't itself.  However
XSLT certainly is.

XSLT, certainly is not a programming language. How did you get that
idea?

Perhaps from the first sentence in the XSLT specification: "This  
specification defines the syntax and semantics of XSLT, WHICH IS A  
LANGUAGE [emphasis mine] for transforming XML documents into other XML  
documents."

Where did you get the idea that XSLT is not a programming language?  What  
definition of programming language are you using in which XSLT doesn't  
qualify?

Pete

Would you call it a programming language at a job interview?

 

[Pherdnut]

[...]

Where did you get the idea that XSLT is not a programming language?  
 What  
definition of programming language are you using in which XSLT doesn't  
qualify?

Would you call it a programming language at a job interview?

Sure.  Why not?

For the same reason I try to use the term 'coding' in general. I tend
to stick with 'scripting' for JavaScript when semantically pressed to
say something other than 'coding.' There's still a crowd out there
that believes anything you don't compile isn't really programming. You
never know what you're dealing with. But as flexible as I am on
academic arguments, I don't really see a point in placing XSLT next to
full blown languages that covers a much wider range of applications.
It's more likely to confuse people than help them and I would wonder
if an interviewee didn't really know his stuff if he talked in terms
of being an XSLT 'programmer.'

 

[Harlan Messinger]

If you don't like it, then don't read it.

If you don't like the rules, don't use the resource.