XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Which is more declarative? More XMLish?

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS