RE: xml element attributes

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: xml element attributes

Judson, Ross
The "if" is a guard on the match/case, so if it fails you'll drop
through to the next case, which here is the default '_' case...the Scala
runtime will throw an exception if a match block doesn't find anything
and you have no default.

Looks like the beta of Scala2 has just arrived, and there are a few
language changes.  After playing around I can say that I definitely like
the new "implicit"!  I wrote a note to the list some time ago about
something I called "ambients".  I think implicit captures the idea
better, at a deeper and more usable level.  Ambients hinged on a notion
of name matching, and I guess that is something that type systems should
not do (unless it forms a dependent type).  Implicits work through types
and scopes only.

RJ

-----Original Message-----
From: Clive Jevons [mailto:[hidden email]]
Sent: Wednesday, January 11, 2006 2:24 PM
To: Judson, Ross; [hidden email]
Subject: Re: xml element attributes

Excellent :D Thanks for the quick feedback. I'll give that a whirl
tomorrow.
I'm just starting out with Scala, so the following might be a really
stupid question ;) Wouldn't I also need an else clause in the second
rewrite rule for the e: Elem case which returns e unaltered if the
attribute does exist:
case e: Elem if (e.attribute("test") == null) => e % testTest else => e
?
Thanks again for your help :)

Cheers,
Clive

On 11 Jan 2006, at 18:22, Judson, Ross wrote:

> Here's a quick example of one way to do it.  I find that the
> RuleTransformer and RewriteRule classes are very helpful.  This  
> does two
> transformations -- it changes bottom level "path" elements to have a
> test attribute with value "symbol", and changes all other elements to
> have a test attribute of "test".
>
> Note the use of inline XML on the first pattern match.  The syntax for
> this stuff is very finicky; what's needed are about fifteen or twenty
> examples of different cases (match leaf with no attributes, match leaf
> with attributes, match interior without an attribute, etc).  As far  
> as I
> can tell you can't pattern match directly against the attributes of an
> XML element via inline XML.
>
> Let's hope the spacing comes through:
>
>   def addTestAttr = {
>
>     import xml._;
>     import xml.transform._;
>
>     val addTest = new RuleTransformer(
>       new RewriteRule() {
>         val testSymbol = new UnprefixedAttribute("test", "symbol",
> Null);
>         override def transform(n: Node) = n match {
>           case s @ <path/> => s % testSymbol
>           case _ => n
>         }
>       },
>       new RewriteRule() {
>         val testTest = new UnprefixedAttribute("test", "test", Null);
>         override def transform(n: Node) = n match {
>           case e :Elem if (e.attribute("test") == null) => e %  
> testTest
>           case _ => n
>         }
>       }
>     );
>     val transformed = addTest.transform(XML.loadFile("c:/def.xml"));
>     Console.println(new PrettyPrinter(140, 2).formatNodes
> (transformed));
>
>   }

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Clive Jevons-2
Cheers :) Thanks for clearing that up - makes sense to me now ;)
Clive

On 11 Jan 2006, at 23:42, Judson, Ross wrote:

> The "if" is a guard on the match/case, so if it fails you'll drop
> through to the next case, which here is the default '_' case...the  
> Scala
> runtime will throw an exception if a match block doesn't find anything
> and you have no default.
>
> Looks like the beta of Scala2 has just arrived, and there are a few
> language changes.  After playing around I can say that I definitely  
> like
> the new "implicit"!  I wrote a note to the list some time ago about
> something I called "ambients".  I think implicit captures the idea
> better, at a deeper and more usable level.  Ambients hinged on a  
> notion
> of name matching, and I guess that is something that type systems  
> should
> not do (unless it forms a dependent type).  Implicits work through  
> types
> and scopes only.
>
> RJ
>
> -----Original Message-----
> From: Clive Jevons [mailto:[hidden email]]
> Sent: Wednesday, January 11, 2006 2:24 PM
> To: Judson, Ross; [hidden email]
> Subject: Re: xml element attributes
>
> Excellent :D Thanks for the quick feedback. I'll give that a whirl
> tomorrow.
> I'm just starting out with Scala, so the following might be a really
> stupid question ;) Wouldn't I also need an else clause in the second
> rewrite rule for the e: Elem case which returns e unaltered if the
> attribute does exist:
> case e: Elem if (e.attribute("test") == null) => e % testTest else  
> => e
> ?
> Thanks again for your help :)
>
> Cheers,
> Clive
>
> On 11 Jan 2006, at 18:22, Judson, Ross wrote:
>
>> Here's a quick example of one way to do it.  I find that the
>> RuleTransformer and RewriteRule classes are very helpful.  This
>> does two
>> transformations -- it changes bottom level "path" elements to have a
>> test attribute with value "symbol", and changes all other elements to
>> have a test attribute of "test".
>>
>> Note the use of inline XML on the first pattern match.  The syntax  
>> for
>> this stuff is very finicky; what's needed are about fifteen or twenty
>> examples of different cases (match leaf with no attributes, match  
>> leaf
>> with attributes, match interior without an attribute, etc).  As far
>> as I
>> can tell you can't pattern match directly against the attributes  
>> of an
>> XML element via inline XML.
>>
>> Let's hope the spacing comes through:
>>
>>   def addTestAttr = {
>>
>>     import xml._;
>>     import xml.transform._;
>>
>>     val addTest = new RuleTransformer(
>>       new RewriteRule() {
>>         val testSymbol = new UnprefixedAttribute("test", "symbol",
>> Null);
>>         override def transform(n: Node) = n match {
>>           case s @ <path/> => s % testSymbol
>>           case _ => n
>>         }
>>       },
>>       new RewriteRule() {
>>         val testTest = new UnprefixedAttribute("test", "test", Null);
>>         override def transform(n: Node) = n match {
>>           case e :Elem if (e.attribute("test") == null) => e %
>> testTest
>>           case _ => n
>>         }
>>       }
>>     );
>>     val transformed = addTest.transform(XML.loadFile("c:/def.xml"));
>>     Console.println(new PrettyPrinter(140, 2).formatNodes
>> (transformed));
>>
>>   }
>

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Lex Spoon
In reply to this post by Judson, Ross
Ross, examples of XML pattern matching that seem unreasonably finicky
would be very helpful, so please post them as you run across them.

I will say that, yes, I am pretty sure attributes are not supported in
the patterns.  So you have to append "if" clauses.


That limitation aside, I have used XML expressions and patterns in the
sbaz toolkit and I have found them regular.  Granted, this might have
to do with easy access to the author, and I just don't remember
something!

Basically, XML patterns and expressions both look like normal XML,
except that { } is an escape that lets you insert regular Scala stuff.
With XML patterns, { } lets you insert Scala patterns.  With XML
expressions, { } lets you insert Scala expressions.

There is some funky stuff to do with handling of spaces, but that
doesn't seem to be what you are talking about.

But to return to the first point, the goal is surely that it is
regular and intuitive.  Any funny-looking examples that people come up
with would be helpful for that goal.


-Lex

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Clive Jevons-2
Hi there,

Just to give you the point of view of someone who is coming to Scala  
fresh:
I couldn't find anything in the documentation which would have helped  
me find the solution that Ross posted - which is why I turned to the  
list in the first place. Some documentation in either the PDFs on the  
web site or in the source documentation together with some examples  
which demonstrate this would be really great.
What attracted me to Scala most was the ability to write XML right in  
with the source code (and that it offered a combination of the OO and  
functional paradigm - but more the XML). So I'd like to have seen  
much more documenation / examples on how to work with XML.
Also, I believe one of the main purposes for creating the language  
was to make it extremely relevant to Web Services ... if I remember  
the blurb correctly :) Hence, as WSs are most often based on XML  
that's another reason to really put some great XML handling docs /  
examples out there ;)
Also, on a slightly related note - will there be support for XML  
Schema in Scala? I know you can use the available Java libraries for  
XML Schema - but they then require the XML documents to be in the  
Java XML library formats as opposed to the Scala native format? (This  
is an assumption, as I haven't actually tried it yet, I'll freely  
admit, so if I'm way off here, please correct me :D)

Cheers,
Clive

On 12 Jan 2006, at 13:07, Lex Spoon wrote:

> Ross, examples of XML pattern matching that seem unreasonably finicky
> would be very helpful, so please post them as you run across them.
>
> I will say that, yes, I am pretty sure attributes are not supported in
> the patterns.  So you have to append "if" clauses.
>
>
> That limitation aside, I have used XML expressions and patterns in the
> sbaz toolkit and I have found them regular.  Granted, this might have
> to do with easy access to the author, and I just don't remember
> something!
>
> Basically, XML patterns and expressions both look like normal XML,
> except that { } is an escape that lets you insert regular Scala stuff.
> With XML patterns, { } lets you insert Scala patterns.  With XML
> expressions, { } lets you insert Scala expressions.
>
> There is some funky stuff to do with handling of spaces, but that
> doesn't seem to be what you are talking about.
>
> But to return to the first point, the goal is surely that it is
> regular and intuitive.  Any funny-looking examples that people come up
> with would be helpful for that goal.
>
>
> -Lex
>

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Lex Spoon
Clive Jevons <[hidden email]> writes:
> I couldn't find anything in the documentation which would have helped
> me find the solution that Ross posted - which is why I turned to the
> list in the first place. Some documentation in either the PDFs on the
> web site or in the source documentation together with some examples
> which demonstrate this would be really great.


Ah, sure enough, that documentation is still being developed.  There
is the beginning of a tutorial here, but it is not finished:

        http://lamp.epfl.ch/~emir/projects/

Also, don't overlook the Scala reference.  It at least *defines* the
XML support, albeit without a lot of examples.


Other than that, I guess for now that the list is the place to go!


> Also, on a slightly related note - will there be support for XML
> Schema in Scala?

Burak can answer best.  I see there is tool called "schema2src" listed
on his home page, which is an intriguing name!  On the flip side, XML
Schema is dauntingly huge, and I'm not sure how well the format is
standardized, even, so I would go slow at raising my hopes!


> I know you can use the available Java libraries for
> XML Schema - but they then require the XML documents to be in the
> Java XML library formats as opposed to the Scala native format?

Sounds right to me, not that I'm particularly clueful in this area.

Note that a fallback strategy is always available: interconvert using
text.  XML is always convertable to and from text, so you can use a
foreign library's internal XML format by going via text, if that makes
sense.


Also, XML is simple.  Probably a person who knows XML well could write
conversion functions pretty quickly between any two formats....



-Lex

Reply | Threaded
Open this post in threaded view
|

RE: Re: xml element attributes

Judson, Ross
In reply to this post by Judson, Ross
I think that what's needed is a "Scala Cookbook", in which we collect a
nice set of "how to" examples.  Certainly the Scala by Example document
is a major step in the right direction.  What I would suggest is that
the Scala community write short problem-solution pairings, and post them
to this list for comment.  The community can then guide the solution
towards optimality.  Once finished, perhaps a new chapter (or chapters)
can be added to Scala by Example that will include these smaller
how-tos.  

I'm going to have a look over the various transformation tasks I've
coded in Scala and see if I can come up with a few concrete, small
problem-solution pairs.  Having the Scala team (especially Burak) look
over the pattern matching and XML stuff will be very helpful.  

It can be tough working from the existing documentation if you're not
sitting over there at EPFL.  ;)  I keep all the Scala code around so I
can go looking for answers...

RJ
 

-----Original Message-----
From: news [mailto:[hidden email]] On Behalf Of Lex Spoon
Sent: Thursday, January 12, 2006 7:08 AM
To: [hidden email]
Subject: Re: xml element attributes

Ross, examples of XML pattern matching that seem unreasonably finicky
would be very helpful, so please post them as you run across them.

I will say that, yes, I am pretty sure attributes are not supported in
the patterns.  So you have to append "if" clauses.


That limitation aside, I have used XML expressions and patterns in the
sbaz toolkit and I have found them regular.  Granted, this might have to
do with easy access to the author, and I just don't remember something!

Basically, XML patterns and expressions both look like normal XML,
except that { } is an escape that lets you insert regular Scala stuff.
With XML patterns, { } lets you insert Scala patterns.  With XML
expressions, { } lets you insert Scala expressions.

There is some funky stuff to do with handling of spaces, but that
doesn't seem to be what you are talking about.

But to return to the first point, the goal is surely that it is regular
and intuitive.  Any funny-looking examples that people come up with
would be helpful for that goal.


-Lex

Reply | Threaded
Open this post in threaded view
|

RE: Re: xml element attributes

Judson, Ross
In reply to this post by Judson, Ross
Again on the topic of XML -- Scala's XML model achieves fairly complete
coverage of the standard.  It's often the case that a smaller subset of
these capabilities is sufficient for translation tasks.  It occurred to
me that there's nothing wrong with having more than one XML model -- for
example, a simple immutable, full immutable (current implementation),
simple mutable, full mutable (like a DOM).  To the extent that these
could share structures, so much the better.  Conversions should be
relatively simple between them, and could also be enabled through
implicits.

The compiler itself will hopefully expose a mixin class for XML
generation, so that the XML model being generated through the parser can
be selected.  Perhaps an annotation can drive the selection of XML model
generator, during parsing.

I don't know if the XML pattern matching capabilities in Scala2 are the
same as those in Scala1.  The XML model in Scala 1 appears to prevent
pattern matching on attributes (perhaps I am wrong about this).  The
language reference appears to indicate that attributes cannot be
attached to XML pattern elements in a match.  Maybe the new matching
capabilities of Scala 2 will allow for more expressive patterns.

RJ
Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Clive Jevons-2
In reply to this post by Lex Spoon
Thanks for the link :D Just finished reading it and posted some  
comments to the list.

As per Russ' suggestion re. Cookbook, here's my attempt at code to  
change the value of an attribute:

        def attTestTrans (attName: String, newAttVal: String):  
RuleTransformer =
                new RuleTransformer(new RewriteRule () {
                        val newAtt = new UnprefixedAttribute(attName, newAttVal, Null);
                        def switchAttr (md: MetaData): MetaData = {
                                if (md == Null) md
                                else if (! (md.key == attName)) new UnprefixedAttribute(
                                                md.key, md.value, switchAttr(md.next))
                                else new UnprefixedAttribute(
                                        attName, newAttVal, switchAttr(md.next))
                        }
                        override def transform (n: Node) = n match {
                                case e @ Elem(p @ _ , l @ _, a @ _, s @ _, c @ _*)
                                if (e.attribute(attName) != null) =>
                                        new Elem(p, l, switchAttr(a), s, c: _*)
                                case _ => n
                        }
                });

Seems kinda kludgy, though - has anyone got a better solution to this?
I certainly would assume that having the option of a mutable XML  
representation could be a huge time-saver in certain situations.  
Failing that, I think that expanding on the cookbook idea and turning  
those useful code snippets into a library might be helpful. Hence,  
you'd have methods like:

changeAttribute(element: Elem, attributeName: String, toValue:  
String): Elem
removeAttribute(element: Elem, attributeName: String): Elem
addAttribute(element: Elem, attributeName: String, attributeValue:  
String): Elem

or for the last one:

addAttribute(element: Elem, metaData: MetaData): Elem

And have these on Utility object? Or a new object called  
AttributeUtility?
Hrm - just 'typing out loud' here, really ;)


Cheers,
C

On 12 Jan 2006, at 18:30, Lex Spoon wrote:

> Clive Jevons <[hidden email]> writes:
>> I couldn't find anything in the documentation which would have helped
>> me find the solution that Ross posted - which is why I turned to the
>> list in the first place. Some documentation in either the PDFs on the
>> web site or in the source documentation together with some examples
>> which demonstrate this would be really great.
>
>
> Ah, sure enough, that documentation is still being developed.  There
> is the beginning of a tutorial here, but it is not finished:
>
>         http://lamp.epfl.ch/~emir/projects/
>
> Also, don't overlook the Scala reference.  It at least *defines* the
> XML support, albeit without a lot of examples.
>
>
> Other than that, I guess for now that the list is the place to go!
>
>
>> Also, on a slightly related note - will there be support for XML
>> Schema in Scala?
>
> Burak can answer best.  I see there is tool called "schema2src" listed
> on his home page, which is an intriguing name!  On the flip side, XML
> Schema is dauntingly huge, and I'm not sure how well the format is
> standardized, even, so I would go slow at raising my hopes!
>
>
>> I know you can use the available Java libraries for
>> XML Schema - but they then require the XML documents to be in the
>> Java XML library formats as opposed to the Scala native format?
>
> Sounds right to me, not that I'm particularly clueful in this area.
>
> Note that a fallback strategy is always available: interconvert using
> text.  XML is always convertable to and from text, so you can use a
> foreign library's internal XML format by going via text, if that makes
> sense.
>
>
> Also, XML is simple.  Probably a person who knows XML well could write
> conversion functions pretty quickly between any two formats....
>
>
>
> -Lex
>

Reply | Threaded
Open this post in threaded view
|

Re: Re: xml element attributes

Jamie Webb-3
In reply to this post by Judson, Ross
On Thu, Jan 12, 2006 at 12:37:20PM -0500, Judson, Ross wrote:
> I think that what's needed is a "Scala Cookbook", in which we collect a
> nice set of "how to" examples.  Certainly the Scala by Example document
> is a major step in the right direction.  What I would suggest is that
> the Scala community write short problem-solution pairings, and post them
> to this list for comment.  The community can then guide the solution
> towards optimality.  Once finished, perhaps a new chapter (or chapters)
> can be added to Scala by Example that will include these smaller
> how-tos.  

It seems like a Wiki would be most convenient for this. I can set one
up if there's a demand.

-- Jamie Webb
Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Clive Jevons-2
I'd welcome / use / contribute to a Wiki :D
Cheers,
Clive

On 12 Jan 2006, at 20:16, Jamie Webb wrote:

> On Thu, Jan 12, 2006 at 12:37:20PM -0500, Judson, Ross wrote:
>> I think that what's needed is a "Scala Cookbook", in which we  
>> collect a
>> nice set of "how to" examples.  Certainly the Scala by Example  
>> document
>> is a major step in the right direction.  What I would suggest is that
>> the Scala community write short problem-solution pairings, and  
>> post them
>> to this list for comment.  The community can then guide the solution
>> towards optimality.  Once finished, perhaps a new chapter (or  
>> chapters)
>> can be added to Scala by Example that will include these smaller
>> how-tos.
>
> It seems like a Wiki would be most convenient for this. I can set one
> up if there's a demand.
>
> -- Jamie Webb

Reply | Threaded
Open this post in threaded view
|

RE: Re: xml element attributes

Judson, Ross
In reply to this post by Judson, Ross
A Wiki would be great!  I think everyone would appreciate it.

RJ
 

-----Original Message-----
From: Jamie Webb [mailto:[hidden email]]
Sent: Thursday, January 12, 2006 2:16 PM
To: [hidden email]
Subject: Re: Re: xml element attributes

It seems like a Wiki would be most convenient for this. I can set one up
if there's a demand.

-- Jamie Webb
Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Geoffrey Alan Washburn
In reply to this post by Judson, Ross
Judson, Ross wrote:

> I think that what's needed is a "Scala Cookbook", in which we collect a
> nice set of "how to" examples.  Certainly the Scala by Example document
> is a major step in the right direction.  What I would suggest is that
> the Scala community write short problem-solution pairings, and post them
> to this list for comment.  

        Or perhaps trendier: a wiki?

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Lex Spoon
In reply to this post by Clive Jevons-2
Clive Jevons <[hidden email]> writes:
> Seems kinda kludgy, though - has anyone got a better solution to this?
> I certainly would assume that having the option of a mutable XML
> representation could be a huge time-saver in certain situations.
> Failing that, I think that expanding on the cookbook idea and turning
> those useful code snippets into a library might be helpful. Hence,
> you'd have methods like:

I'll leave the nitty gritty to Burak.

In general an immutable representation can be just as simple as a
mutable one.  In general, the tradeoff is something like:

  mutable:
    - faster in some cases

  immutable:
    - easier to work with (no solving alias problems in the head)
    - faster in many practical cases


The reason immutable structures can be faster in practice is that
programmers don't insert extraneous clone() calls all over the place
just in case.


Theory aside, an expression for changing an attribute could be as
simple as this:

        elem % "foo" -> "bar"


An attribute rewrite, which sets attribute "foo" to "bar" on all
"somtag" nodes, could look like this:

        GeneralRewrite({
          case t @ <sometag>{_}</sometag> =>
              t % "foo" -> "bar"
        })


Actually using the above rewrite rule could look like this:

        val newtree =
            oldtree.rewrite({
              case t @ <sometag>{_}</sometag> =>
                  t % "foo" -> "bar"
            })


There are just some quick ideas.  The point is, immutable data
structures can certainly be used with concise expressions....


-Lex

Reply | Threaded
Open this post in threaded view
|

Re: xml element attributes

Clive Jevons-2
You're right, of course :) I'm just hankering for some mutable  
attributes because that's what I know and I haven't found / been  
shown an easy way to accomplish it with the current Scala  
implementation ;) So really what I should have asked for is an easier  
way to manipulate attributes :D Its just that in my head I'm thinking  
myElement.setAttribute("someName", "someValue"). Doesn't get much  
more concise than that ;) So if there's a way to express it as  
concisely in Scala I'll be a happy bunny :)
Cheers,
C

PS: I do profusely apologies for the smilie onslaughts you'll  
encounter in my posts - its just that I've taken to substituting  
emoticons for correct punctuation ;) Can't help myself!

On 13 Jan 2006, at 11:22, Lex Spoon wrote:

> Clive Jevons <[hidden email]> writes:
>> Seems kinda kludgy, though - has anyone got a better solution to  
>> this?
>> I certainly would assume that having the option of a mutable XML
>> representation could be a huge time-saver in certain situations.
>> Failing that, I think that expanding on the cookbook idea and turning
>> those useful code snippets into a library might be helpful. Hence,
>> you'd have methods like:
>
> I'll leave the nitty gritty to Burak.
>
> In general an immutable representation can be just as simple as a
> mutable one.  In general, the tradeoff is something like:
>
>   mutable:
>     - faster in some cases
>
>   immutable:
>     - easier to work with (no solving alias problems in the head)
>     - faster in many practical cases
>
>
> The reason immutable structures can be faster in practice is that
> programmers don't insert extraneous clone() calls all over the place
> just in case.
>
>
> Theory aside, an expression for changing an attribute could be as
> simple as this:
>
>         elem % "foo" -> "bar"
>
>
> An attribute rewrite, which sets attribute "foo" to "bar" on all
> "somtag" nodes, could look like this:
>
>         GeneralRewrite({
>           case t @ <sometag>{_}</sometag> =>
>               t % "foo" -> "bar"
>         })
>
>
> Actually using the above rewrite rule could look like this:
>
>         val newtree =
>             oldtree.rewrite({
>               case t @ <sometag>{_}</sometag> =>
>                   t % "foo" -> "bar"
>             })
>
>
> There are just some quick ideas.  The point is, immutable data
> structures can certainly be used with concise expressions....
>
>
> -Lex
>