[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin said:
> Hello Juan,
Hi,
> Didier replies:
> A lot of languages based on XML were developed but few have practical
> interpreters associated to them. For instance, CML has several
> interpreters able to translate elements of the language into visible
> objects. XBRL has several interpreters able to process the language
> elements into spreadsheets and more elaborate models (for stock
> picking). A language based on XML becomes useful when processors are
> also provided with it; otherwise it is only the result of some spare
> glucose metabolism and not a useful tool :-)
>
> If you count XML based languages having a set of interpreters made
> available for public consumption, the number of 600 is reduced to less
> than 50 (and I am overly optimist here)
Well i obtained the number from
[http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages]
See also
[http://xml.coverpages.org/xmlApplications.html]
I did not check the implementation level of development of each one.
> Didier replies:
> Juan, the DOM is only an interface to something else. It's an
> abstraction or a facet offered for public consumption, it's not the
> object per se. A DOM is a public interface but behind the curtain you
> have something else. For example, in the Gecko engine, each HTML element
> is translated (i.e. interpreted) into a visual object. Idem for IE.
> Visual objects have several properties set by either HTML element
> attributes like for instance the width or height (when available) or set
> by CSS properties. Thus, the real object presenting a DOM interface is a
> lot more than the DOM. It's a set of methods and properties some made
> public like the DOM some made private. It is also an area laid on a 2D
> layout, hence the notion of visual object. In the case of VoiceXML, the
> result of the interpretation is sound. Hence the notion of aural objects
> placed in a time sequence. The real object keeps some properties like
> the element tag, this is why we can retrieve its origin. But also, at
> least in the case of IE, if you request a serialization of its current
> state you'll get all properties attached to the object. The ones defined
> as attribute in declarative code (for the browser an HTML document is
> declarative code) and the one dynamically attached to the object at
> run-time. <div> and <p> inherit from the same "block area" object and
> the object inheriting the "block area" features add some properties and
> methods, they may be different though even they are both a "block area".
> The world as seen by the browser is clearer when seen through its own
> perspective or the object oriented perspective. For a browser an HTML
> element is no longer and solely an HTML element, it became something
> else an aggregation of different things {a visual object, a DOM object,
> an ECMAScript object, etc...} At run-time and within a browser an HTML
> is a lot more than specified at first in with markups.
Now understand you.
> Didier replies:
> XSLT can be perceived as a general purpose XML interpreter. It allows
> you to assemble different XML documents into a single one, have
> different interpretation strategies for each fragment or vocabulary. For
> instance, I can add new vocabularies to an XHTML document and provide an
> XSLT template that will use other template/interpreter for other
> vocabularies I am including in the XHTML document. This way, the
> language becomes eXtensible.
Yes, but is not eXtensible in that way i said. Reason that if you have a
<grocery-list> at the server side and you can manipulate the semantics,
but you finalize with something as <ul> at the client side if you want
your doc can be 'understood'. The situation is still poor when you cannot
rely on a XSLT or CSS for full funcionality: e.g. CML.
Different XML tags cannot be asembled in the way i said. That is reason
that new tags may be invented. E.g. XHTML2 <blockcode> for the current
sequence of <pre><code>. If you can combine available tags in a
multimarkup system then you can directly use something like the composed
tag <<pre><code>>. You cannot do this in XML and, therefore, XHTML WG
needs add a _new_ tag: <blockcode>.
When explosion of languages arise in a future, the posibility for reusing
available tags -instead invent new ones- will become so crucial like
combination of fragments of code in PL.
> Didier replies:
> Yes this is what I mean. In the last project I was working on for
> several years and that was maybe the most ambitious AJAX based project I
> came to the conclusion that what is needed in an intelligent
> interpreter. In many cases, the system was not responding because the
> pre-conditions weren't met and no intelligent message was provided to
> the users. So I started to display messages about what the engine is
> doing, then I still got the same precondition errors when, for example,
> the users disabled the javascript option. So, I am updating the engine
> with a new algorithm
>
> a) check pre-condition: for example, the very first condition for the
> engine to run is to have javascript enable. If not, the engine should
> display an error message and a procedure for users to set the javascript
> to on or make this site as "trusted". So, not only providing an error
> message but also indicating what to do. Same thing if the java VM is
> disabled, etc... This is why I came to the conclusion that an
> environment has to be defined for a proper interpretation (an
> interpretation being in my case a rendition). Based on this definition,
> the layer provided for the datument can check if the latter can survive
> in this host. If not, at least the user is made aware of what is wrong
> and what to do.
Interesting, because i suspect i would find a similar problem with a
project i have in my mind now.
> Cheers
> Didier PH Martin
> http://didier-martin.com
Juan R.
Center for CANONICAL |SCIENCE)
|
