Rich: (01)
An XML parser has nothing to do with client server architecture nor is
such implied. It *can* be used within CS architectures but there is no
dependence on such. XML parsing also does not require that a network is
present of any type. (02)
Parsing is simply "reading" without understanding. The only thing that
matters is that the XML is well formed or, in the case of a schema or DTD
validation required, is compliant with the rules expressed in such. Where
or why the XML is being parsed is simply orthogonal to the parsing. (03)
I know it has a very large following as I have personally been involved
since almost day one ;-) (04)
Unfortunately, it is relatively easy to develop one's own XML based
dialect and this was a relatively popular activity through much of the
late 1990's and early 2000's. For some reason, a lot of the people
developing the XML dialects wanted others to see their work. (05)
XML and JSON are both here to stay. (06)
If anyone wants to know how they are parsed and how DOM structures are
built, I am happy to donate a couple of hours to be a guest on one of the
weekly calls to explain this so we are all on the same page. (07)
Best wishes, (08)
Duane (09)
***********************************
Technoracle Advanced Systems Inc.
Consulting and Contracting; Proven Results!
i. Neo4J, PDF, Java, LiveCycle ES, Flex, AIR, CQ5 & Mobile
b. http://technoracle.blogspot.com
t. @duanenickull (010)
NOTICE: This e-mail and any attachments may contain confidential
information. If you are the intended recipient, please consider this a
privileged communication, not to be forwarded without explicit approval
from the sender. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal. The
originator reserves the right to monitor all e-mail communications through
its networks for quality control purposes. (011)
On 2014-02-03 9:50 PM, "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx> wrote: (012)
>Dear John, Duane and Paul,
>
>XML is a standard with a VERY large following. It
>is often used for event processing, and for
>interchange of highly structured data between
>diverse computers and diverse applications. For
>that reason, it is relatively easy for a
>standardized XML form to be interchanged. But it
>is very difficult to develop your own standard XML
>form; at least it is very difficult compared to
>JSON.
>
>Languages such as Delphi have XML parser
>components built into the IDE. There are two
>kinds of such XML parsers which are both free to
>the average programmer with an IDE. One component
>type takes its syntax from a file containing a
>specification of the objects, attributes and
>domains of a defined standard, while the other
>kind takes it syntax from nothing whatsoever, and
>just parses the XML into objects, attributes, and
>domain values.
>
>Event processing is typically accomplished by the
>client sending a request in XML, and the server
>responding with the XML binding to values relevant
>to the event semantics. A sequence of such
>messages makes up the entire event stream.
>
>For example, the title of real estate properties
>tends to be expressed in an awkward textual
>description of the meets and bounds of the
>property. That text is mostly unstructured, but
>other objects and attributes and values of the
>same XML message can be simple scalars designed to
>help process the event messages.
>
>For the defined standards (or even for your
>particularly defined application even if it is
>unique), the parser does lots of error checking
>and provides exceptions wherever the standard is
>not met, either by omission or by commission.
>That makes it valuable in applications where such
>errors are made too frequently. Typically that is
>for programmer-generated forms that go through
>several iterations until the programmers find a
>deterministic path through the standard.
>
>The other kind, where the programmer defines a
>unique "standard" used only by that server and
>that client in a specific application, is less
>useful because it lacks such detailed error
>checking. However, it still provides the rigidity
>of XML forms meant to convey the proper semantic
>information in an easily harnessed manner.
>
>XML is here to stay, IMHO, because it fills the
>void left by lack of a truly semantic vehicle for
>transmission of messages. For now, XML is the
>best choice, though it could certainly use
>improvement over time.
>
>Also, IMHO, English (or other natural language) is
>the best vehicle for semantic transmission, but we
>have yet to perfect the mechanics of it.
>
>-Rich
>
>Sincerely,
>Rich Cooper
>EnglishLogicKernel.com
>Rich AT EnglishLogicKernel DOT com
>9 4 9 \ 5 2 5 - 5 7 1 2
>-----Original Message-----
>From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
>[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
>Behalf Of Paul Tyson
>Sent: Monday, February 03, 2014 9:00 PM
>To: [ontolog-forum]
>Subject: Re: [ontolog-forum] fitness of XML for
>ontology(WAS: [ontology-summit] The tools are not
>the problem (yet))
>
>On Mon, 2014-02-03 at 09:55 -0800, Duane Nickull
>wrote:
>> JSON is a generalized markup. I can use the key
>values to describe any
>> other domain.
>
>Sure you can. Like Humpty-Dumpty, you can pay any
>string of characters
>extra to do whatever you want it to do. But you
>typically have to pay
>less for them in XML because the XML parser does a
>lot of the tedious
>work for you. Take for example the class of
>well-paid strings known in
>SGML as "generic identifiers", or in XML simply as
>"element names". They
>are instantly recognized by the XML parser as
>markup, whereas a key
>value in JSON is just another key value until the
>programmer writes some
>code to handle it otherwise.
>
>The "generalized" part of generalized markup
>applies to grammar as well.
>You can construct your own markup tokens at will
>without having to
>reconfigure the parser. If your application (or
>development process)
>requires validation of the markup, it falls out of
>the box with XML. Not
>so with JSON.
>
>>
>> XMl has nothing to do with semantics.
>
>I'm not sure what you mean here, but I think I
>agree, and I call it
>goodness. The purpose of a markup language is
>first off to separate one
>string of characters from another, and secondly to
>guide the parser in
>putting the various chunks in different buckets so
>the application can
>do something useful with them. I don't know in
>what sense "semantics" is
>needed or wanted for these operations.
>
>>
>> XML has the ability to make data portable and
>can be used to transfer
>> ontological or semantic models, or fragments
>thereof, between applications.
>
>Understated but accurate.
>
>Regards,
>--Paul
>
>
>__________________________________________________
>_______________
>Message Archives:
>http://ontolog.cim3.net/forum/ontolog-forum/
>Config Subscr:
>http://ontolog.cim3.net/mailman/listinfo/ontolog-f
>orum/
>Unsubscribe:
>mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/
>To join:
>http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePa
>ge#nid1J
>
>
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/
>To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> (013)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (014)
|