On 12/2/2017 9:26 AM, Costello, Roger L. wrote:
> Hi Folks,
>
> XML documents oftentimes contain a set of things – a set of books, a set
> of people, a set of transactions, etc.
>
> Typically, a set isn’t allowed to contain just anything, the set must
> satisfy some constraints.
>
> Constraints can be expressed in different ways. Perhaps one way is
> better than another? Perhaps one is more declarative, the other more
> imperative? Perhaps one is XMLish, the other not?
> [clip...]
> Recap: We’ve seen two ways to specify (constrain) a set:
>
> (a) State a property (or properties) that an object must have to qualify
> as a member of the set.
>
> (b) Define a set of rules which generate its members.
>
> Which way is better? Which is preferred? Which is more declarative?
> Which is more XMLish?
>
> /Roger
Rules can be described using a rules language. If you like one that is
"XML-ish", then you're good.
OWL is good for defining properties. OWL classes, properties, etc. can
be expressed in RDF-XML. Many people don't like the XML syntax, but for
classes and class properties, you can write the RDF-XML in a pretty
clean way that's fairly easy to read. If you consider this to be
sufficiently "XML-ish", then you're good.
Any and all of your constraints can be expressed using Conceptual
Graphs, which can express all of first order logic and some of second
order. Topic Maps are basically a subset of Conceptual Graphs. So you
could probably devise a way to use Topic Maps for your constraints and
rules, although it doesn't exist as yet. Topic maps can be serialized
into a standard XML format. You would be good.
What's more to the point - as it seems from what you have asked - is how
you can get from the expression of your rules or properties to checking
the validity of a document against them. That's a whole other thing
entirely. Or perhaps you really want to know how to sift through a
collection of candidate set members and output an XML document that only
contains the actual members.
If you have some OWL definitions that outright specify class members,
it's not hard to write code to serialize a specialized document
containing those members. In fact, if you get an standardized XML
version of the OWL, you could write an XSLT stylesheet to do it. For
some examples, see my Extreme Markup paper from 2007, "Easy RDF For
Real-Life System Modeling", at
http://conferences.idealliance.org/extreme/html/2007/Passin01/EML2007Passin01.html
If you have some OWL that specifies certain properties or property
values on class members, then OWL processors can figure out which among
some candidate members are actually class members of your class(es).
Presumably you could serialize these results into some XML format.
Sparkle (the RDF query langiage) may be all you need if you can get your
candidates into OWL/RDF.
If you want to use a rule language, then again you would get a
serialized output and then transform it into some XML format that you
like. Schematron might be an example, for those rules that it can
handle, depending on what kind of output you can persuade it to emit.
So it would seem that you could work up a tool set to do a particular
job along the lines of what you asked about. Doing it for a general
case, that would be a bigger step.
I don't know if any of the above is sufficiently "XML-ish". That's
because you have stepped way outside of what XML per se is all about.
As for being declarative, OWL/RDF is declarative, Topic Maps is
declarative, rules processors may or may not be declarative. Schematron
is declarative. Sparkle is declarative. Javascript/python/perl/etc
processing of serialized output into XML would probably not be
declarative, but XSLT processing would be.
I have a work flow that runs python scripts to serialize files in
certain directories into an intermediate XML format, then uses a series
of XSLT transformations to finally produce javascript files that will
get loaded into a browser to produce the interactive displays I want.
That's probably going to be your typical work flow in many cases: a mix
of declarative and procedural processing.
TomP
