[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Updates was Re: XML-aware programming language?


dogtype
<snip/>

I'll take the cue for the lack of updates in XML programming languages.

Daniela Florescu wrote:

>
> This "three legs animal" as someone called it is a technical aberration.
> There are no technical reasons for things to be that way.
> I don't think the situation can continue like this for a long time.
>
There are worse things that persist (and he even got margins of 3 million:-)

I agree with you, and it reminds of Bjarne Stroustrup's infamous 
interview which claims C++ is just there to raise programmer salaries 
(IT WAS A JOKE). 
http://www.just2good.co.uk/index.php?funStuffFrameSet.php?stroustrup.htm

I think some time has to pass in order for the right balance to be found 
between expressivity and convenience. IMHO languages without static 
typing are less convenient. They also offer a lot less potential for 
automatic optimization.

But the question is how can you combine static typing with updates?

Suppose you have declarations like (in an notation that lets you express 
the same things as in XML Schema)

element zoo:ZooType
type ZooType = animal:AnimalType*

abstract element animal:AnimalType
type AnimalType = ()

element dog:DogBreed substitutes for animal:AnimalType
type DogBreed = name:Name breed:Dogs

element cat:CatBreed substitutes for animal:AnimalType
type CatBreed = name:Name breed:Cats

Now I have a

let $z = zoo(
  dog(name(Efes) breed(borderCollie))
  cat(name(Mia) breed(persian))
)

I want to replace the dog Efes with Cleo, a mixed breed dog.

let $efes = $z / dog[ name(Efes) ]
let $cleo = dog(name(cleo( )) breed(mixedBreed( )))
$z.replace($efes,$cleo)

Alternative syntax could be $z / $efes := $cleo or whatever.

How can a compiler find out whether $efes is actually a child of $z? One 
may restrict assignments to situations where this is possible. Then the 
compiler can actually see that the type of $cleo is the same as the type 
of $efes.

But what if $cleo was a cat?

The compiler has to clever and find out that the content of $z are nodes 
animal:AnimalType, that cat:CatType is in the substitution group of 
animal. Fine.

But what if the type of zoos was different?

type ZooType = dog:DogType* cat:CatType*

Then the replacement would only be well-typed if $efes was the LAST dog 
that appears in the list. That is beyond the powers of typechecking, and 
one can only do with reasonable approximations.

For the same reasons, updates like z.child[3] = $cleo etc. are not 
really viable.

The problems do not really appear with objects, because these do not use 
regular expressions to type their members of a class.

I'd appreciate any helping comments on this. I am only interested in 
static type checking. All I know is that for some regular word 
transformations can be modeled with finite state word transducers, and 
undecidability of type checking results from undecidability properties 
there.

kind regards,
Burak Emir

http://lamp.epfl.ch/~buraq

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.