[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl6-language
Subject:    Re: xml and perl 6
From:       Richard Hainsworth <richard () rusrating ! ru>
Date:       2007-11-30 12:26:22
Message-ID: 4750016E.5040704 () rusrating ! ru
[Download RAW message or body]

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/divp[@id='mydivid'] ] = "new text value";
>
> This would replace text context node of a div with an id of the value
> of $myperlvar
>
>     $html[/html/body/divp[@id=$myperlvar] ] = "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
>   
[prev in list] [next in list] [prev in thread] [next in thread]