Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] A categorization of XML technologies based on the kind of rules they express

From: "Rushforth, Peter" <Peter.Rushforth@-----------.--.-->
To: "Costello, Roger L." <costello@-----.--->,<xml-dev@-----.---.--->
Date: 5/4/2009 4:07:00 PM
Hi Roger,

I've long thought that XSLT was an excellent language for expressing
rules.

* XSLT is declarative, thus allows to express (sometimes complex)
relationships between inputs.
  Although this could be construed as burying rules in code,  I think
the next fact can mitigate against this.
* XSLT is XML, and thus can be managed (stored, queried, presented,
updated) as data by many databases.

One issue I see is that rules need to be expressible (presented) in a
way that is comprehensible to non-programmers.  Rules themselves need to
be adaptable to express simple or complex logic, which may make them
difficult to interpret by non-experts. Nevertheless, they need to be
able to be as fine-grained as necessary.  I've often wondered if MathML
content markup couldn't be transformed into actionable XSLT in a way
that adapted the rule to the context.  So some combination of MathML and
XSLT togther could constitute a 'business rule markup language', which
could be transformed to xhtml (with xforms) for presentation/ update or
pure XSLT for execution.

Anyhow I thought you missed XSLT entirely, unless it came in under the
heading of XProc.

Cheers,
Peter




>     Below I categorize some XML technologies 
>     based on the kind of rules they express. 
>     Following that I describe the importance 
>     of making rules explicit (i.e. not buried 
>     in code) and assert that the collection of 
>     rules for a business define its collective 
>     intelligence. I welcome your thoughts.
> 
> 
> 
> CATEGORIZATION OF XML TECHNOLOGIES BASED ON THE KIND OF RULES 
> THEY EXPRESS
> 
> 
> EXPRESSING PROCESS OR WORKFLOW RULES
> 
> I identify four XML technologies for expressing process or 
> workflow rules:
> 
> 1. BPEL
> 
> 2. XProc
> 
> 3. NVDL
> 
> 4. Schematron
> 
> BPEL expresses rules for orchestrating Web services.
> 
> XProc expresses rules for processing XML documents.
> 
> NVDL expresses rules for partitioning XML documents and 
> dispatching each part to the appropriate validator.
> 
> Schematron expresses rules for progressive validation: each 
> <phase> element may map to a step in a process or workflow.
> 
> 
> 
> EXPRESSING DATA VALIDITY RULES
> 
> I identify four XML technologies for expressing data validity rules:
> 
> 1. NVDL
> 
> 2. Schematron
> 
> 3. XML Schema
> 
> 4. RELAX NG
> 
> Notice that NVDL and Schematron express both process/workflow 
> rules and data validity rules.
> 
> 
> 
> EXPRESSING USER INTERFACE RULES
> 
> I identify two XML technologies for expressing user interface rules:
> 
> 1. CSS
> 
> 2. XForms
> 
> 
> 
> EXPRESSING DATA RELATIONSHIP RULES
> 
> I identify two XML technologies for expressing data 
> relationship rules:
> 
> a. RDF Schema
> 
> b. OWL
> 
> 
> Here is a diagram showing this categorization:
> 
> http://www.xfront.com/Categorization-of-XML-Rules-Technologies.gif
> 
> 
> By deploying these XML technologies it externalizes the 
> thinking of an organization.
> 
> 
> Note: In the following sections I quote liberally from 
> "Business Rules Applied" by Barbara von Halle.
> 
> 
> 
> MAKE RULES EXPLICIT 
> 
> Too often the rules are implicit or buried in code. This 
> makes it difficult to change the business. Users and 
> developers are forced to guess and make assumptions. 
> 
> Make explicit the rules of the business. This enables you to 
> deliver better changeable systems faster.
> 
> Create systems in which the rules are:
> 
> - separated from other components so everyone knows *that* they exist
> 
> - externalized so everyone knows *what* the rules are
> 
> - traceable to their origins and their implementations so 
> everyone knows *where* the rules come from
> 
> - deliberately positioned for change so everyone knows *how 
> to improve* them
> 
> 
> 
> COLLECTION OF RULES = COLLECTIVE INTELLIGENCE
> 
> The collection of rules across an enterprise is its 
> collective intelligence. They determine who an organization 
> is and what it can become. They can be challenged and 
> analyzed. They are the inspiration and primary guidance 
> system for collective behavior. They are the mechanisms by 
> which an organization changes itself.
> 
> 
> /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@l...
> subscribe: xml-dev-subscribe@l... List archive: 
> http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> 
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent