Oops I left out ' not' in a critical sentence: 3rd time this week. Apologies:antibiotics making me woozy maybe.
Anyway, the 'it' is not xml in that sentence: 'it' is the schema languages that do NOT allow looking at information beyond the single document.
Grammars could be extended to cope with webs in a similar way that relax ng handles attributes: imagine
Pattern hyperlink-to-p =
Element a (@id?, @href->p)
Where -> means to get the resource at @href and go to the root or fragment node which must be a p element. Just POX and URLs.
This kind of grammar could be considered a web technology in a way that dtds, xsd and relax ng are not. I don't know whether it would give enough bang to be worth it: but it was one of the surprises of schematron to me -- how much easier life is if you don't need to worry about the entity/ resource/document boundaries of your data.
Now am I stretching the point by saying that the document-scoped schema languages are not just web-unhelpful but positively web-retarding? Obviously it is a generalization, but I certainly think it is real and a factor at play.
Why cannot schema languages check for dangling pointers, for example? Why cannot schema languages just check with an efficient web service "does this url have a representation xml document" or whatever? Modelling information is hard: when the physical and logical modelling is intertwined ( by limited-scope schema languages) it can be harder.
Rick
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