Hi,
I have to format output for an application that requires its XML to
have attributes quoted using double, not single quotes.
Is there any way to coerce REXML into producing double-quotes?
Ian
–
Ian Macdonald | QOTD: "The baby was so ugly they had to
System Administrator | hang a pork chop around its neck to get
ian@caliban.org | the dog to play with it."
http://www.caliban.org |
>
Ian Macdonald ian@caliban.org wrote in message news:20030622205120.GE3769@caliban.org…
I have to format output for an application that requires its XML to
have attributes quoted using double, not single quotes.Is there any way to coerce REXML into producing double-quotes?
Soon, young Jedi. I’m adding some more configurable XML writers to
REXML 3.0.
FYI, the application is not XML conformant if it doesn’t accept single
quotes around attributes.
In the meantime, if you really need this and are willing to hack the
sources, override REXML::Attribute::to_string(). Do something like
this in the application that generates the XML:
REXML::Attribute.class_eval( %q^
def to_string
%Q[#@expanded_name="#{to_s().gsub(/"/, '"')}"]
end
^ )
This will rewrite the method that is used to produce the XML fragment
for an Attribute.
— SER
Ian Macdonald ian@caliban.org wrote in message news:20030622205120.GE3769@caliban.org…
I have to format output for an application that requires its XML to
have attributes quoted using double, not single quotes.Is there any way to coerce REXML into producing double-quotes?
Soon, young Jedi. I’m adding some more configurable XML writers to
REXML 3.0.FYI, the application is not XML conformant if it doesn’t accept single
quotes around attributes.
Yes, I know. I couldn’t believe it when I finally discovered why my
files weren’t being accepted.
In the meantime, if you really need this and are willing to hack the
sources, override REXML::Attribute::to_string(). Do something like
this in the application that generates the XML:REXML::Attribute.class_eval( %q^
def to_string
%Q[#@expanded_name=“#{to_s().gsub(/”/, ‘"’)}"]
end
^ )This will rewrite the method that is used to produce the XML fragment
for an Attribute.
Thanks very much, Sean.
Ian
Ian Macdonald | Time sharing: The use of many people by the
System Administrator | computer.
ian@caliban.org |
http://www.caliban.org |
>
Ian Macdonald ian@caliban.org wrote in message news:20030624010502.GH7020@caliban.org…
FYI, the application is not XML conformant if it doesn’t accept single
quotes around attributes.Yes, I know. I couldn’t believe it when I finally discovered why my
files weren’t being accepted.
If I may digress, I’d like to re-make on observation about software
developers.
When I first started REXML, I just wanted an easier API for accessing
XML. I wasn’t particularly interested in full conformance, and at the
time I was only intending to support a small subset of XPath.
After the initial development, I was spending more time using REXML
than working on it, but as more people used REXML, I received an
increasing number non-conformance bug reports. Eventually, it became
fully conformant with full XPath support. Now all I have to worry
about is XPath 2.0. 
I think a lot of projects linger in that limbo of supporting enough
features that the original developer doesn’t have any interest in
expanding the project, and being “complete” (whatever that means).
The difference is that critical mass of complimentary users, who are
enthusiastic about the project. I’ve been lucky enough to have a few
users who even submit bug fixes, which in no small part contributes to
my continued interest in working on REXML. I don’t think a lot of
people understand what a difference receiving patches makes; it sort
of makes you feel more obligated to work on the project, since other
people are. As a result, I want to thank everybody who’s submitted
patches, bug reports, suggestions, and messages of encouragement to
REXML.
In any case, there was another point I wanted to make: as I spend more
time working on REXML, I find that I increasingly have to resist
making changes that would make REXML less intuitive. I suspect that
this is because XML itself has some features that tend to influence
implementations; Namespaces is the biggest culprit. Namespaces are
inherantly complex, and they complexify the API. There’s the
“correct” way to do them, that reflects how Namespace support is
defined in the specification, and then there’s the intuitive,
programmatically easy way. Unfortunately, if you do them the correct
way, the XML API immediately becomes obtuse to casual XML users. If
you don’t, then it is very difficult to have them behave as an XML
expert would expect. For example, take the following pseudo-code:
a = Element.new( "a", "some namespace" ) # create <a> in namespace
“some namespace”
b = a.add_element( “b” )
What namespace is “b” in? Is “some namespace” the default namespace
for “a” and its children? No matter how you solve this problem, the
result is an API that is tedious to use. I’m still struggling with
this, and probably will be, until XML is replaced by something else.
The result is that it is critical to me to have users that offer API
suggestions, even if most are rejected. Sure, I want to keep things
easy, but you get to close to the code, and you start thinking about
the problem from the wrong point of view… and you end up writing
some monstrosity like DOM. This is the single greatest hazard to
specifications: authors who don’t to use their own creations, who
think of the problem only from a design standpoint. For this reason I
love Ruby, which has somehow maintained its simplicity. I’d be
willing to bet that Matz writes as much code in Ruby, as he does
for Ruby. Either that, or he has an inordinate amount of
self-control to keep looking at Ruby from a user’s point of view,
rather than a developer’s point of view.
[This message was posted from a tool that has no spell checker.
Sorry.]
— SER
…defined in the specification, and then there’s the intuitive,
programmatically easy way. Unfortunately, if you do them the correct
way, the XML API immediately becomes obtuse to casual XML users. If
you don’t, then it is very difficult to have them behave as an XML
expert would expect. For example, take the following pseudo-code:a = Element.new( “a”, “some namespace” ) # create in namespace
“some namespace”
b = a.add_element( “b” )What namespace is “b” in? Is “some namespace” the default namespace
for “a” and its children? No matter how you solve this problem, the
result is an API that is tedious to use. I’m still struggling with
this, and probably will be, until XML is replaced by something else.
May I offer the suggestion of a “context” object that defines /all/ the
namespaces and mappings to their prefixes, and then, all one has to do
is:
context = new Context({'foo', 'http://foo.org/b',
'', 'http://www.w3.org/somewhere'})
context.do {
a = Element.new("foo:a")
b = a.add_element("b")
}
the element “b” would get the w3.org namespace, and foo:a would get the
foo.org namespace.
It’s implementable with a little hacking, with a thread variable to hold
the current context, and the context.do method could be a little ugly
push-popping that and tweaking in the thread namespace. Quite doable,
though, and easy to use, I think – you define your namespaces similarly
to as in XML, where they’ve a lexical scope on all contained elements,
and here, on all contained statements. They’re nestable, which would be
nice, too.
It’s a thought, anyway, and if anyone has ideas that don’t use thread or
global variables, I’d love to see them, because I want an API for XML
that’s not a monster. REXML is as close as exists so far, I think.
A sidenote: Sean, I’d like to pick your brain some time, since I’m
planning to set up a way of indexing content of XML documents in a
separate index file, and it may make XPath searches much faster and add
the possibly of disk-based access instead of parse-whole-tree access of
docs for XPath.
Be well, all.
Ari
Aredridel aredridel@nbtsc.org wrote in message news:1056644378.17774.30.camel@mizar…
May I offer the suggestion of a “context” object that defines /all/ the
namespaces and mappings to their prefixes, and then, all one has to do
is:context = new Context({‘foo’, ‘http://foo.org/b’,
‘’, ‘http://www.w3.org/somewhere’})
context.do {
a = Element.new(“foo:a”)
b = a.add_element(“b”)
}the element “b” would get the w3.org namespace, and foo:a would get the
foo.org namespace.
This is an interesting idea. I was thinking along the same lines, but
with setting the context in the node tree itself:
a = doc.add_element(“a”) # New element, no namespace
a.define_namespace( “foo”, “http://foo.org/b” )
# Assoc. namespace w/ prefix
a.namespace = “http://foo.org/b” # Set a’s namespace
b = a.add_element(“b”) # Add b to a; no default (no)
# namespace
c = a.add_element(“c”, “http://x.org”)
# Add c to a in x.org namespace
d = c.add_element(“d”) # Add d to c, in default (x.org)
# namespace
e = c.add_element(“e”, ‘’) # Add e to c, w/ empty namespace
My hesitation with doing things this way is that it marginalizes
prefixes, which is how XML is defined. However, it is not the way
people think about namespaces. It also hides the nature of default
namespaces, which I really don’t like.
A sidenote: Sean, I’d like to pick your brain some time, since I’m
planning to set up a way of indexing content of XML documents in a
separate index file, and it may make XPath searches much faster and add
the possibly of disk-based access instead of parse-whole-tree access of
docs for XPath.
If you can think of a way to do this, I’d really like to hear about
it. At one point I wrote a version of XPath that used indexed trees,
in the hopes that I could speed it up. I discovered that the time
consuming aspects of XPath are things that are not indexable:
predicates. Predicates must be evaluated in the context of a node.
Ironically, having to deal with namespaces also really slows down
XPath searches. In the end, the cost of indexing a document offset
any speed gains the indexing provided; in fact, for simple ‘a/b’
XPaths, the indexed version was only faster where the indexing cost
was amortized over multiple searches.
It sounds like you’ve got something in mind that bypasses parsing the
XML document at all, which would be interesting; to be honest, I can’t
imagine how you could evaluate an XPath in that context, but feel free
to email me about it – I’d love to hear your ideas.
— SER
This seems similar to APIs in XOM, which I’ve been reading about. Have
you looked at it, and the design discussion behind it?
Sam
Quoteing ser@germane-software.com, on Sat, Jun 28, 2003 at 04:30:34AM +0900:
the element “b” would get the w3.org namespace, and foo:a would get the
foo.org namespace.This is an interesting idea. I was thinking along the same lines, but
with setting the context in the node tree itself:a = doc.add_element(“a”) # New element, no namespace
a.define_namespace( “foo”, “http://foo.org/b” )
# Assoc. namespace w/ prefix
a.namespace = “http://foo.org/b” # Set a’s namespace
b = a.add_element(“b”) # Add b to a; no default (no)
# namespace
c = a.add_element(“c”, “http://x.org”)
# Add c to a in x.org namespace
d = c.add_element(“d”) # Add d to c, in default (x.org)
# namespace
e = c.add_element(“e”, ‘’) # Add e to c, w/ empty namespaceMy hesitation with doing things this way is that it marginalizes
prefixes, which is how XML is defined. However, it is not the way
people think about namespaces. It also hides the nature of default
namespaces, which I really don’t like.A sidenote: Sean, I’d like to pick your brain some time, since I’m
planning to set up a way of indexing content of XML documents in a
separate index file, and it may make XPath searches much faster and add
the possibly of disk-based access instead of parse-whole-tree access of
docs for XPath.If you can think of a way to do this, I’d really like to hear about
it. At one point I wrote a version of XPath that used indexed trees,
in the hopes that I could speed it up. I discovered that the time
consuming aspects of XPath are things that are not indexable:
predicates. Predicates must be evaluated in the context of a node.
Ironically, having to deal with namespaces also really slows down
XPath searches. In the end, the cost of indexing a document offset
any speed gains the indexing provided; in fact, for simple ‘a/b’
XPaths, the indexed version was only faster where the indexing cost
was amortized over multiple searches.It sounds like you’ve got something in mind that bypasses parsing the
XML document at all, which would be interesting; to be honest, I can’t
imagine how you could evaluate an XPath in that context, but feel free
to email me about it – I’d love to hear your ideas.— SER