By the time this got written, I see James has bowed out of the
discussion with some words about 'architectural break points'. Even so,
my two-penniworth:
JF gave some examples of how he would like xml to be 'a part of core'.
For clarity, I use xml and I have designed a language to describe
financial scoring models as xml. To process the language _in perl_ I
looked at a variety of processing approaches before deciding on
XML-Twig. Note there were different approaches and they are
fundamentally different. I choose the one that suited me and the problem
space best.
Hence the design philosophy underlying perl6 encourages this
flexibility. So despite my own current preferrence for xml as a data
description methodology, I absolutely agree with the perl6 design.
Some more analysis:
<snip>
first a few assumptions;
we will probably never want to 'address' xml in perl ... e.g. perl
format will never become declarative markup and there is no reason to
start wanting to somehow mix code/data lisp style in perl
a) why is this true? The flexibility in perl6 with its ability to morph
its own input grammar makes it entirely possible to consider
interspersing output markup with processing commands. "Consider" is the
important word. Whether such an approach would be aesthetically pleasing
is entirely another question. I do find php to be quite ugly. However,
suppose someone comes up with a nice way of doing it, great ...
another thing to admit is that an XML type would probably just be an
XML document .... well formed and adhering to the rules of XML v1.0
.... going beyond that and stating it must be an XML Infoset is going
too far.
b) Why a document? and look at the snippits below, they are not
documents, unless my understanding of what a document is differs from
that being implied in this posting.
c) For me, xml means a way of encapsulating data in a clear cut way.
-----------------------
Here are some examples of psuedo syntax I would find useful (which I
have borrowed from things like XQuery, e4X, etc);
---------------------------------
declaring some xml in one's perl program;
---------------------------------
my $sales = <sales vendor="John">
<item type="peas" price="4" quantity="6"/>
<item type="carrot" price="3" quantity="10"/>
<item type="chips" price="5" quantity="3"/>
</sales>;
d) My problem with this snippit is that there is no context in the sense
of a problem space that is being tackled. What is the whole script
trying to do? Why is it so important to loose the bracketing syntax of
quotation marks that would identify the right hand side as a normal user
defined object?
e) It would seem from the entire xml email thread that JF equates xml
fragments with integers and strings. But look at the xml fragment above.
"4" is an integer, "peas" is a string. In other words, the xml fragment
is itself built up from more fundamental data types. Hence xml is not so
really fundamental or "core", but rather as a common method of
aggregating data. Perl6 is designed to allow for the creation of objects
that aggregate data.
f) From what I understand about Perl6 is that the fragment given about
could easily be a part of a Perl6 script. However, a "use
XML-Scripting;" statement would need to be included that would introduce
the appropriate grammar rules so that i) the xml fragments are correctly
parsed and assigned, and ii) all the other parts of the script would
parse correctly and unambiguously.
g) Given the length of time it has taken to develop Perl6 (FAR TOO
LONG!!!!!!!, I would humbly suggest as a user who wants to see Perl6 in
real life), and the careful discussions that have gone into all aspects
of syntax and grammar, it is by far not obvious to me that creating a
module that handles xml as above would be trivial.
no surrounding quotes seems about right.
however this leads to some 'other thoughts, like how does perl and xml
play nice together....
h) Perl6 and xml would play nicely together if some talented programmer
creates a nice playground, viz. an elegant and unified syntax that
excludes the other ambiguities of the real world.
what about;
my $html = <html><head/><body>
<span>
<h1>{ $sometitlevar }</h1>
i) If you like this type of scripting - and I really dont - I can see no
reason why you cant design a module to do this with perl6.
j) By the way, all of these snippets are html not xml, or rather there
are no xml examples here that are not html. JF, do you work with xml or
with html?
<ul>
{
loop ($counter = 1; $counter < 20; $counter++) {
<li>Try to count electric sheep . . . </li>;
}
}
</ul>
</span>
</body></html>
I have eschewed with explicitly having a print statement, as a
syntactic shortcut.
k) But why? Create an 'XML-Scripting' module and I would imagine it to
be possible for perl6 to export any value that is of type xml directly
to an output stream.
when it comes to manipulating XML, there are a few axioms...
---------------------------------
How to Address parts of an XML document variable ?
---------------------------------
It is common to want to address a portion of an XML document
my $select_li_elements = $html.html.body.span.ul ;
this syntax is ok (actually I do not like this approach), but I like
my 'scanability' to be in xpath form ala:
my $select_li_elements = $html[/html/body/span/ul/li];
and then u have the expressive power of xpath inside of these brackets.
so when declaring a var as xml, it would be this
my $data is XML;
( as an aside, is there any concept of the native types, Scalar,
Array, Hash being in a different namespace then all the other symbols
e.g. could I override Scalar type ?)
l) For someone who is so forcibly putting forward the inclusion of xml
into the language, it might have been wise to discover the answer to
this question first....
next,
---------------------------------
How do I update an XML document variable ?
---------------------------------
Here are a few edit type examples reusing the XPATH syntax introduced earlier;
This would replace text context node of <div id="mydivid"/>
$html[/html/body/[EMAIL PROTECTED]'mydivid'] ] = "new text value";
This would replace text context node of a div with an id of the value
of $myperlvar
$html[/html/body/[EMAIL PROTECTED] ] = "new text value";
This would replace XML children of ul element
$html[/html/body/span/ul] .= <li>some new bullet point</li>;
This would remove XML children of ul element
$html[/html/body/span/ul] .= null;
I am unsure of what an append scenario would look like.
---------------------------------
And what about validation?
---------------------------------
Perhaps one would like to be able to decide if this xml must be
checked for validaty against some schema technology (DTD and relaxNG
as basic) .... are there any 'adjectives when declaring a type ... I
guess I am suggesting a new sigil enforcing an XML context ;0
m) a NEW sigil???
then there is the 'processing' XML bit .....
---------------------------------
Iterating through XML
---------------------------------
should print out the value of each div contained in html
for $myxmlvar[/html/body/div]]{
print; # prints $_, the current loop variable
}
I will stop here ... so I can put on my flame proof suit.
n) For each of these suggestion, my response has been why not? The whole
beauty and power of the perl6 design as it stands now is to allow a
programmer to do just what has been suggested. However, it will require
a programmer to use perl6 to do this, but also to design the rules that
will be unambiguous and elegant.
o) In a very real sense, the true answer to JF is that all he wants is
already in Perl6 and it is as much a part of the "core" as CGI, database
interaction, etc. But in order to tap the power of the Perl6 core, he
has to define the behaviour he wants, and to write the module.
Richard
cheers, Jim Fuller
