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] A categorization of XML technologies based on the kind of rules they express

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@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
> 
> 


[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