ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] fitness of XML for ontology(WAS: [ontology-summit] T

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Rich Cooper" <rich@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 4 Feb 2014 11:42:49 -0800
Message-id: <430A56A0E5FE4C40AD7F16395574C690@Gateway>
True, XML is a message type, and its use is not
necessarily always client/server or N-tier.  But
modern message handling methods in significantly
large distributed systems tends to be either
client/server or N-tier for other reasons, such as
ability to isolate each interchange for debug and
testing purposes.      (01)

Essentially, nearly every business application of
size is client/server or N-tier because those are
the most practical architectures in today's
technology.      (02)

But you are exactly correct; XML has nothing to do
with the method of file exchange.      (03)

-Rich    (04)

Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2    (05)

-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On
Behalf Of Duane Nickull
Sent: Tuesday, February 04, 2014 9:23 AM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] fitness of XML for
ontology(WAS: [ontology-summit] The tools are not
the problem (yet))    (06)

Rich:    (07)

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.    (08)

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.    (09)

I know it has a very large following as I have
personally been involved
since almost day one ;-)    (010)

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.    (011)

XML and JSON are both here to stay.    (012)

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.    (013)

Best wishes,    (014)

Duane    (015)

***********************************
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    (016)


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.    (017)






On 2014-02-03 9:50 PM, "Rich Cooper"
<rich@xxxxxxxxxxxxxxxxxxxxxx> wrote:    (018)

>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?WikiHomeP
a
>ge#nid1J
> 
>
> 
>_________________________________________________
________________
>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
>     (019)



__________________________________________________
_______________
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    (020)



_________________________________________________________________
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    (021)

<Prev in Thread] Current Thread [Next in Thread>