Re: Interplatform (interprocess, interlanguage) communication
- From: BGB <cr88192@xxxxxxxxxxx>
- Date: Wed, 08 Feb 2012 18:49:05 -0700
On 2/8/2012 3:02 PM, Lew wrote:
BGB wrote:...
an example is this:
<foo> <bar value="3"/> </foo>
and:
(foo (bar 3))
now, consider one wants to add a new field to 'foo' (say 'ln').
<foo ln="15"> <bar value="3"/> </foo>
and:
(foo 15 (bar 3))
a difference here is that existing code will probably not even notice
the new XML attribute, whereas the positional nature of most
Ahem. You mean other than failing schema validation?
many of us don't use schemas with our XML.
I think the issue is that one particular technology, XML, is used in significantly different ways by different people and for different reasons.
many people use XML for data-binding, and many other people who use it could care less about data-binding.
some people may use XML for similar purposes to how people using Lisp would use lists (never-mind if this is kind of awkward, it does work).
like, doing Lisp type stuff in Java using DOM-nodes in place of cons-based lists... +1 now that Java also (sort of) has closures.
S-Expressions makes the latter far more likely to break something (and
More likely than failing schema validation was for that well-designed XML-based
application?
as noted, many people neither use schemas nor any sort of schema validation. in many use-cases, schemas are overly constraining to the ability of using XML to represent free-form data, or using them otherwise would offer little particular advantage.
say, if one is using XML for compiler ASTs or similar (say, the XML is used to represent a just-parsed glob of source-code), do they really need any sort of schema?
http://en.wikipedia.org/wiki/Abstract_syntax_tree
there is no good way to "annotate" an S-Exp, whereas with XML it is
fairly solidly defined that one can simply add new attributes).
Attributes in XML are not annotation (with or without quotes). That role is filled by the actual 'annotation' element
http://www.w3schools.com/schema/el_annotation.asp
they can be used for annotating the nodes in many sane use cases...
a lot depends on how one is using the XML in a given context.
note: my main way of working with XML is typically via DOM-style
interfaces (if I am using it, it is typically because I am directly
working with the data structure, and not as the result of some dumb-ass
"data binding" crud...).
Sorry, "dumb-ass 'data-binding' crud"?
Why the extreme pejoratives? I would not say that there's anything wrong with
XML data-binding /per se/, although as with documented-oriented approaches it
can be done very badly.
yeah, this may have been stated overly strongly.
personally, IMO, data-binding is probably one of the worse and technically more pointless ways of using XML (as, IMO, it leads to such similarly ill-designed technologies as SOAP and similar...).
not that data-binding is itself necessarily itself pointless, but doing it via overly verbose namespace-ridden XML is probably one of the worse ways of doing it (vs either specialized file-formats, or the use of binary data-binding formats, which IMO should also not be used for data interchange).
admittedly, I also partly dislike traditional ways of using data-binding as it often exposes things which are theoretically internal to the app, namely structural data representation (via classes/...), with things which should theoretically be isolated from the internal data representation: file formats.
or, IOW: a file-format (or protocol/...) should express the data in itself, and not express how it is physically represented within the application.
likewise, data going into or coming out of a piece of code should be ideally documented and defined in a form separate from the component in question.
otherwise, data-binding is not that much different than a more modern variant of writing raw structures and arrays to files.
typically, the "internal representation" and "concrete serialization"
are different:
I don't understand what you mean here. You cite these terms in quotes as though
they are a standard terminology for some specific things, but use them in their
ordinary meaning. The internal representation of what? The serialization
("concrete" or otherwise) of what? I don't mean to be obtuse here, but I am not
grokking the referents.
the internal representation of the data within the application code.
if one knows which objects or classes exist, what sorts of members they contain, ... then one is essentially exposing data which should not be visible, or for that matter relied upon for data interchange (or, for that matter, relevant).
ideally, any data represented externally should be defined in terms of its semantics: something will be present if it is relevant to the meaning of the data. the serialization will then be defined in terms of expressing the structure and semantics of the data, which may bear very little resemblance to how the data is represented in the actual classes/arrays/whatever which make up how the data is represented internally to the application.
similarly, file formats should be as much abstracted from the application code as is reasonably possible, with a "concrete" specification for the file-format or data-representation being written instead.
both XML and S-Expressions can be used as structured ways of representing semantics, rather than as ways of representing the contents of given a data-object.
I may use a textual XML serialization, or just as easily, I could use a
binary format;
likewise for S-Exps (actually, I probably far more often represent
S-Exps as a binary format of one form or another than I use them in a
form externally serialized as text).
all hail the mighty DOM-node or CONS-cell...
WTF?
DOM nodes can be very powerful (and are probably a much better way of using XML than using it as some sort of data-binding thing).
cons-cells are pairs of dynamically-typed values, typically called "car" and "cdr" and used to implement lists and similar (and are the main building block of "everything" in languages like Lisp and Scheme, well, along with "symbols" and "fixnums" and similar).
http://en.wikipedia.org/wiki/Cons_cell
they can also be implemented in C, C++, and Java without too much trouble, and can be a fairly useful way of building various sorts of data structures (although, sadly, they aren't nearly as efficient in Java as they could be, but OTOH it is also sort of a pain to build a dynamic type-system in C, so it probably evens out...).
then one can proceed to build logic based mostly on building and processing lists.
or, conceptually, they can be regarded as a type of linked-list based containers, however the ways they are traditionally used are significantly different from traditional ways of using containers (they are typically used as ways of building tree-structures, rather than usually as ways of storing a collection of items).
it may be worthwhile to look-up information regarding Lisp and Scheme and similar, not that there is necessarily much reason to actually use the languages, but there are some ideas and ways of doing things which can be mapped fairly nicely onto other, more common, languages.
.
- Follow-Ups:
- Re: Interplatform (interprocess, interlanguage) communication
- From: Arne Vajhøj
- Re: Interplatform (interprocess, interlanguage) communication
- References:
- Re: Interplatform (interprocess, interlanguage) communication
- From: jebblue
- Re: Interplatform (interprocess, interlanguage) communication
- From: BGB
- Re: Interplatform (interprocess, interlanguage) communication
- From: Arved Sandstrom
- Re: Interplatform (interprocess, interlanguage) communication
- From: BGB
- Re: Interplatform (interprocess, interlanguage) communication
- From: Lew
- Re: Interplatform (interprocess, interlanguage) communication
- Prev by Date: Re: How do I scp extremely large files
- Next by Date: Re: Interplatform (interprocess, interlanguage) communication
- Previous by thread: Re: Interplatform (interprocess, interlanguage) communication
- Next by thread: Re: Interplatform (interprocess, interlanguage) communication
- Index(es):
Relevant Pages
|