xml + ruby

[paul vudmaska]

---------
James Britt <[email protected]>
I suspect it's the context. Many (most?)
ECMAscripters are doing web
development and are perhaps mainly focused on the data
and markup;
scripts are just another way to manipulate
pointy-bracketed data, not
manage complete business processes. So adding
markup-centric syntax
sort of makes sense.
-----------<<

My interest for it is for web stuff for sure and maybe
that has led to the disconnect here. Good point.

ecmascript is a class oriented general purpose
scripting language just like Ruby and it is used (a
lot!) supporting the entire business cycle - just like
you would with java or language x or ruby. It is just
not compiled. Witness the use of ECMAScript (as
opposed to vbscript) with ASP/IIS. We used it in a
large cororation for moderately large applications
with great success because of it's simplicity and
class orientation, which allowed us to protect our
code. It is 'missing' cool things like interpolation
and iterators - but it is quite sound, imo, and not
some 'scripty' thing like you suggest. Much of m$'s
site is written with this - some of it even works .
Ecmascript if my favorite language on tues,thurs.
Knock it if you want ;/


As for the conflict with characters in ruby names,
unfortunately I can suggest no obvious solution -
maybe use xpath where the easy way is not acceptable.
Also someone mentions 'just getting to the element he
wants' without using a long path. Again, xpath, would
be the direct/best approach perhaps.


v




__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

 

[James Britt]

ecmascript is a class oriented general purpose
scripting language just like Ruby and it is used (a
lot!) supporting the entire business cycle - just like
you would with java or language x or ruby. It is just
not compiled. Witness the use of ECMAScript (as
opposed to vbscript) with ASP/IIS. We used it in a
large cororation for moderately large applications
with great success because of it's simplicity and
class orientation, which allowed us to protect our
code. It is 'missing' cool things like interpolation
and iterators - but it is quite sound, imo, and not
some 'scripty' thing like you suggest. Much of m$'s
site is written with this - some of it even works .
Ecmascript if my favorite language on tues,thurs.
Knock it if you want ;/

I'm not knocking it; I'm aware of it's features, have used it quite a
bit, and I like it a lot.

http://www.jamesbritt.com/index.rb/2003/Sept/23#The_Kewlness_of_JavaScript

But my impression is that, despite Ecmascript's qualities as a language,
it has been surplanted by JSP/Servlets/Java and marginalized (however
unfairly) as a "mere" Web scripting lanaguage. I can't remember the
last time I saw a job ad mentioning server-side javascript.

As with Ruby and other langauges, once some people have relegated a
language to the scripting ghetto it is hard to get them to see it any
differently.

James Britt

 

[Eric Hodel]

--ByM1h5nouWwd3kz8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

There's further confusion if you had:
=20
<list><item>1</item><item>2</item><item>3</item></list>
=20
How would I refer to each individual item: list.item[0] through
list.item[2]? If the <list> tag also allowed for CDATA values,
there's nothing in the XML spec that would prevent:
=20
<list>cdata<item>1</item>cdata<item>2</item>cdata</list>

Ruby <--> XML seems to be a poor fit, it seems XML will quickly
become too verbose with all the exceptions and having to resort to
XPath (I've seen several posts that say "oh, we'll have to use XPath for
that", and that wouldn't make me very happy). Ruby <--> RDF would
be a better fit, especially if used as a serialization format.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--ByM1h5nouWwd3kz8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/fZLqMypVHHlsnwQRArVQAJwPaXBfSnLU04vX9y5XvY190ZJOJACgmGBU
WsvZ+JdFEfKwv3yQwguOlCw=
=WNpE
-----END PGP SIGNATURE-----

--ByM1h5nouWwd3kz8--

 

[Eric Hodel]

--csgZZokDzjk698W/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

=20
I'm not sure I understand what you're saying, especially as RDF is an XML
format.

The biggest problem I've seen above is that XML documents are just being
made up without any schemas or relationships to other documents. The
best thing about XML is the namespaces, because you can write <clothing:tie=
/>
and <rope:tie/> and know that the two are different contexts. (Even
though nobody seems to do that, which is a real shame.)

Unfortunately, there's no way to tell what way two different namespaces
are related to each other, and this is where RDF comes in.

RDF has an XML serialization format, but you can store RDF in any format
you want. RDF's strength is its focus on relationships, and what you
can infer from the ones given. Here's some RDF in subject, predicate,
object triples:

<urnerson:Sandra> -> name -> Sandra
<urnerson:Sandra> -> gender -> female
<urnerson:Sandra> -> sibling -> <urnerson:Kevin>
<urnerson:Kevin> -> name -> Kevin
<urnerson:Kevin> -> gender -> male
<urnerson:Kevin> -> parent -> <urnerson:Sarah>
<urnerson:Sarah> -> name -> Sarah
<urnerson:Sarah> -> gender -> female

With this data, you can easily infer that:

Sandra has a brother.
Sandra's mother's name is Sarah.
Sarah has at least two children.

And since everything can be given a namespace that maps back to the
basic RDF types, you can easily pass this information in and out of
other systems, and everybody will know what you are talking about.

Specifically, serializing Ruby objects in XML is a waste if only Ruby
can understand the generated XML. Nobody else can understand the
relationships and easily use them into other systems. Using RDF, the
relationships are easily parseable for use in other systems, making
them interoperable without pain. =20

I've had good results with the use of REXML for XML processing. I don't d= o a
lot with XML, but I can't fault the API for that. REXML can, of course, be
used in either "DOM" or stream/SAX mode, and if the DOM mode is too verbo= se
for the purposes of processing, then the SAX mode can help -- I think.

Yes, I agree everything I've done with REXML has been straightforward
and simple. I'm just pointing out that throwing XML into the midst of
things isn't going to necessarily give you any direct gains without a
bit of thought.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--csgZZokDzjk698W/
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/fefIMypVHHlsnwQRArW0AKDWL0+tgphCc+dwKTmfNJlOMr/TvgCfYeu6
5KSm56F1oH/Z7oEwen9mCRM=
=gHhX
-----END PGP SIGNATURE-----

--csgZZokDzjk698W/--