Rick, could you expand on that? You wrote:
"It [XML] inhibits integrity checking, QA, QC, validation and verification: it
retards the progress of the web by excluding webs of data from the sweet
spot in favor of single large documents."
I have not yet understood. What inhibition are you thinking of? What exclusion?
I think that XML has amazing properties for exactly this, the validation of complex system state, expressed as a set of distributed documents. XML+XQuery offer: (a) outstanding addressing capabilities (the magic formula: URI + XPath), (b) outstanding capabilities of aggregation/filtering. Note that (a) and (b) taken together provide us with the possibility to express the "thing", "feature" or "property" to be validated in a uniform way - as sets of information items and their relationships. To accomplish the validation we then have at our command an expression language (XQuery) which operates on those things in a native way.
The change of paradigm I am waiting for is a new perception which sees documents as contributions to a single, homogeneous space of information, I am waiting
for a widespread recognition that documents have a dual nature - distinct entities, *and* just part of a homogeneous substrate of information, which is the forest of information items effectively created by the sum total of accessible XML resources. Documents are like a fishnet plus the water (& fish) contained, located in a lake: the information contained, and the information surrounding are part of a homogenous substrate, where the homogeneity is provided by the uniformity of the node model plus the uniformity of the navigation model (XPath).
Oh, we DO need an extension of our concept of "validity", embracing multiple documents. Restricting "validity" to single documents is a limitation which is not any longer natural. It was *the* view when thinking was pre-URL. But we should look forward, not backward. One of the first steps: treating document references as a built-in data type, making it a basic concept of our information
model.
So... could you expand on the inappropriateness of XML when it comes to system validation, or to the treatment of distributed information in general?
Hans-Juergen
Rick Jelliffe <rjelliffe@allette.com.au> schrieb am 0:30 Mittwoch, 11.Dezember 2013:
There are some vocabularies out there. XCsp I see. I don't know if rdf has a story.
I briefly worked for TI supporting AI systems 25 tears ago. It was the tail end of AI, and the knowledge capture problem was the big gotcha.
One of my surprises is that xml/json/csv has not resulted in a resurgence of AI, solvers and logic programming. We have so much data now.
Another thing we found then was that programmers could accept simple expert system just based on cases (Schematron's design): but using the more elaborate search mechanisms or higher order logic repelled them, I think because programmers like to think if themselves as the problem solvers.
(btw I was told that schematron is? used to check for intersecting flight routes above central Europe.)
Rick
On 11/12/2013 1:59 AM, "Costello, Roger L." <
costello@mitre.org> wrote:
Hi Folks,
When I fly from Boston to Washington D.C. on Southwest airlines, I sure hope the airlines have coordinated with each other and there isn't, say, a United airplane that will be at the same route point at the same time as my Southwest airplane.
Identifying conflicts is important.
My example is one of identifying conflicts among geometric shapes: we can represent the route of the Southwest airplane as a set of shapes (cylinders, spheres, points, etc.) and we can similarly represent the route of the United airplane. Then we can do some math and determine if there are any conflicts among the shapes.
3-D shapes are not the only things that can have conflicts. Suppose Southwest has an airplane available from 0800 to 1600 on Friday and someone needs an airplane on Friday between 1000 to 1300. That's an example of a conflict: is there an overlap between an airplane's availability and the need for an airplane. However, unlike the previous example, there are no geometric shapes involved in identifying this conflict. (Also, in this example conflict is a desired thing whereas in the previous example conflict is an undesired thing.)
So the two examples seem to be quite different: the first involves identifying conflicts among geometric shapes and the second involves identifying conflicts among resource availability and resource need.
But surely there is a common thread that ties them together? After all, they both involve identifying conflicts. So what is the common thread that ties them together?
...... I have learned that what I describe above are instances of Constraint Satisfaction Problems (CSP).
So, I would like to express my constraints in XML and feed the XML into a CSP tool. Has anyone created an XML vocabulary for expressing constraints?
Thanks!
/Roger
_______________________________________________________________________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
