Altova Mailing List Archives

Re: [xml-dev] InnerXml is like printf (WAS: Underwhelmed)

From: Miles Sabin <miles@----------.--->
To: Arjun Ray <aray@----.--->, xml-dev@-----.---.---
Date: 9/22/2002 10:52:00 AM
Arjun Ray wrote,
> | InnerXml _is_ printf ... but that doesn't mean we couldn't have
> | something analogous to printf which has its nice features (domain-
> | specific little language) without the risk of non-well-formedness.
> I suppose by "nice features" you mean variable substitution, which is
> the value of a template.  I also assume that there's protection
> against the classic printf disaster of short arglists.

Err ... no, not especially. I mean that the template syntax can fit the 
job, rather than having to be shoe-horned into the host languages 
syntax (example later).

> I think the bigger fight is not with Java syntax, but with GP
> expectation. The default mindset first time in the door is probably
> one of "I gotta write strings, why can't I write strings?"

Hire smarter programmers?

>   1.  &Deity; forbid that I should make a mistake in *xpath* syntax!
>       (who catches that, how, and when?  Looks like runtime to me.)

Sure, at runtime ... tho' presumably the _first_ runtime, so it's not 
too dreadful.

>   2.  How do I splice other stuff?  Or do I have to put the entire
>       tree into a single expression?

How about,

  Element link =
    new Element(
     { "/ss/style.css" } );

  Element e =
    new Element(
      { "Example 3", link, "Hello World" } );

>   3.  What about adding more than one child to an element?

Already in that example (head and body, title and link). Like I said, 
this is a mish-mash of XPath and s-exprs.

>   4.  Do concise arrays allow a mixture of heterogenous objects? How
>       do substitute subtrees in?

Yup, and illustrated above.

> I'm really not convinced this is a win.  Not to mention that XPath
> reeks too much of Obligatory HighTech.  I have to write a xpath-expr
> parser too just to support this?  Aiyaiyai!

Probably _you_ don't. An implementor of such an API could do it just the 
once, and it'd be applicable across all vocabularies. OTOH you'd have 
to write (or generate) a new library for every vocabulary. FWIW, I 
don't think code generation is going to do a very good job without 
manual intervention, cp. JAXB's mapping schemas.

> | Oh, and BTW: Hungarian notation is an abomination ;-)
> I agree (it wasn't quite Hungarian notation, except perhaps for the
> 'e' prefix on the locals).  Hungarian notation is a decent idea taken
> to a ridiculous extreme.
> The 'a' prefix on element construction methods and 'w' (for "with")
> on attribute methods were necessary in order to prevent clashes with
> Java reserved words.

This is the example of fighting the host languages syntax I alluded to 
earlier. There are a few nasty examples in the HTML DOM.




These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.