Re: [xml-dev] Which is more declarative? More XMLish?

[Thomas Passin <list1@tompassin.net>]

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