Re: Putting the cart before the horse?

Thanks Greg,

I've already experienced the benefits of declarative binding between syntax/XML and model/POJO via JAXB; I guess what I was fishing for, but unable to ask for in a concise way, was how, in your opinion, a desire to make use of such binding approaches should influence the design of the node object model, parsers, serializers, etc.

I don't see how the binding support needs to be anything more than a layer over the basic XML syntax libraries, rather than needing any tighter coupling. But not seeing what's right in front if my face is something of a talent of mine, so who's to say? :)

And my suggestion to defer spending a lot of time discussing it was based simply on a desire to try to get everyone's attention focused on ensuring that that lowest layer be as reliable, coherent and simple as possible.

Believe me, I'm a lot more excited by the higher-level, semantic use cases than the syntactic basics, but I don't believe it will be possible to achieve the former without the latter.

Thanks again for engaging with this sausage factory. :)

-0xe1a----- Reply message -----
From: "Meredith Gregory" <lgreg.meredith@gmail.com>
Date: Sun, Dec 13, 2009 2:41 PM
Subject: [scala-xml] Putting the cart before the horse?
To: <scala-xml@listes.epfl.ch>

Dear Alex,
Since you asked i will do that. i'm out of time on this for today, but will get you a small sample, tomorrow. In the meantime, on the OCamlDuce site i found both an atomrss reader sample and an aaxl (the xml verison of aadl). If you can read Scala and whenever you see in OCaml 'let ptn = expr'  you think 'val ptn = expr' you ought to be able to transliterate in your head (ok, that might be a slight exaggeration...). Beyond that, reconsider my example
Point.xsd:
<complexType name="Point">   <complexContent>      <sequence>          <element name="x" type="float"/>         <element name="y" type="float"/>       </sequence>   </complexContent></complexType>
ought to map to
case class Point( x : Float, y : Float )
And then you ought to have the following verifiable property, (sprinkle quantifiers as needed)
{ ( x : Float, y : Float ) =>   { validate( serialize( Point( x, y ) ), "Point.xsd" ) == true } } // The fact that this function must return true for all x and y in Float says that validation coincides with typing
as well as the verifiable property
{ if ( validate( "point.xml", "Point.xsd" ) ) {     deserialize( "point.xml" ).isInstanceOf[Point] == true } } // The fact that whenever the test is true the true branch always returns true says typing coincides with validation
This will allow someone to write things like
deserialize( "point.xml" ) match {    case Point( x, y ) => sqrt( x*x + y*y )}
And the fact that it compiles will mostly do away with the need for runtime validation. Again, if people want a different schema language, you can achieve this in several ways, including:

• JAXB supports multiple schema languages, including RelaxNG (i think);
• Trang -- put out by RelaxNG's author -- supports schema conversion, as does Oxygen.

But, take this example and recast it in the existing framework. Someone has to build by hand the case class and then someone has to build by hand the serialization/deserialization mechanism for Point. That's repetitious and error-prone and no-one gets any support from the type system. Their deserialization mechanism could completely subvert typing, for example, which would be a mistake. If you want to convert to a different type -- say from Point to Vector -- then keeping track of the conversion *with types* is important for many reasons.
Best wishes,
--greg

On Sun, Dec 13, 2009 at 1:44 PM, Alex Cruise <alex@cluonflux.com> wrote:

Meredith Gregory wrote:

<snip/>
If one works with these biases, instead of against them, which are in turn aligned with much deeper principles, then the way is paved for much greater productivity and use cases that we have not yet discussed. Continued work at the merely syntactic level will serve to limit ScalaXML usability -- which i find sad -- especially since
   * CDuce/OCamlDuce was much further along than ScalaXML as early as
     2005, and it was done by just 1 guy (btw, has anyone in this
     thread, besides myself, actually looked at these language
     offerings? Scala's design as a language owes a great deal to OCaml.)

Greg,

I sincerely wish I was able to intuitively grasp your point, and I feel like we would be well served by giving serious consideration to your advice, but I lack the experience in reading OCaml and/or the intelligence to fully understand what I'm looking at.  I'm loath to add to your workload, but maybe if you could distill what you feel to be the central contributions of OCamlDuce, and produce a quick sketch of what some analogous Scala library/language features might look like, I know it would help me (and, I suspect, others) a great deal.

Thanks!

-0xe1a

--
L.G. Meredith
Managing Partner
Biosimilarity LLC
1219 NW 83rd St
Seattle, WA 98117

+1 206.650.3740

http://biosimilarity.blogspot.com