Policy MDE vs. MDE Policies

MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: Policy MDE vs. MDE Policies




From: 
To: 
Date: Mon, 26 Sep 2005 10:45:38 -0700









One of my 'ToDos' from the last face-to-face (at 
CTC9)...
...was to compose an email to restate my position on 
our approach to 'policy'.
 
The debate is really about this: 

  Should there exist a single, 
  consolidated policy set, describing the behavior of all implemented MDEs 
  participating in a system?  Or, should each implemented MDE express its 
  own policy set, describing the behavior and code-sets of that specific 
  MDE?
I think John poetically described the issue this way: 
"Is there a PolicyMDE... or are there MDE 
Policies?"
 
To understand my position, you first need to understand 
how I perceive 'policies'.
 
I see 'Policy' as the MDEs' "rules of 
engagement" - a set of rules to describe the interactive behavior 
of our implemented MDEs 
 
'Policy' can describe things such 
as:
- The valid codes you may use or 
expect when performing an interaction with the 
MDEs.
- The argument extensions or restrictions to the 
'normalized' set of MDE interactions.
- The set of (link to) business rules regarding 
MDE interactions (court hours, font size).
 
Furthermore, I see policies as 
describing the interactions of any our implemented 
MDE.
 
Others see 'Policies' as describing (or 
controlling) only interactions with the court, whether it be an 
interaction we have categorized as FilingReview, or whether it is an interaction 
we have assigned to CourtRecord.   Their point of view is often 
reflected in their nomenclature: 'Court Policies', rather than 
simply 
'Policies'.  
 
To be fair, all of the Policies we have 
discussed so far, happen to only be concerned with how we interact with the 
court.  For example, we have not yet discussed policies for 
FilingAssembly, because, coincidentally, our scope has not 
officially recognized any queries or transactions into the 
FilingAssembly MDE (aside from a Callback function), though, we all agree that 
FilingAssemblyMDE could define transactions and queries, and, 
presumably, those interactions would then have the potential to have 
associated policies.
 
Perhaps, the lingering 'Court Policy' 
concept reflects that some of us are not entirely on-board with the 'MDE' 
approach to the system.  That's fair enough - MDE is merely an architectural 
concept which might or might not be successful for us in the long run - but, 
nevertheless, at this point, for this version of LegalXML, 
we have decided to pursue the MDE approach, and, I feel, we need to be 
thoroughly consistent with it.
 
If we have agreed to organize 
our court interactions into 'FilingReview' and 'CourtRecord', then, we should 
also agree to categorize the MDE's 'rules of engagement' along those same 
lines:

  These are the 'FilingReview' 
  rules...
  And Those are the 'CourtRecord' 
  rules...
At the face-to-face, I 
seemed to get some decent buy-in on that concept.  It was noted that 
some of our rules (such as query extensions/restrictions) are distinctly 
MDE-specific, and those policies should therefore be organized by 
MDE.  
 
But, just because we might agree that policies should 
be organized by MDE, does not mean that they could not continue to be 
consolidated into a single file.  The question 
remained: Should there exist a single file to express all policies of all 
implemented MDEs?.. or should the system consist of  multiple 
policy files, one per implemented MDE?
 
So, do we want to see something like 
this?:

  SystemPolicy
      CourtRecord (MDE 
  1)
          
  CodeSet1, QueryExtension2,  QueryRestriction3, 
  etc.
      FilingReview (MDE 
  2)
          
  CodeSet1, QueryExtension2,  QueryRestriction3, 
  etc.
   
Or, something like 
this?:


  Policy-1 for CourtRecord ( MDE 1 
)
          
  CodeSet1, QueryExtension2,  QueryRestriction3, 
  etc.
   
  Policy-2 for FilingReview 
  ( MDE 2 )
          
  CodeSet1, QueryExtension2,  QueryRestriction3, 
  etc.
 
Now, I look around me for another real-world 
example of the proposed singleton approach.

I can think of none.
 

- Some may 
refer to Windows registry as an example of a consolidated set of 
rules


  First of all, this is a bad example: WindowsRegistry 
  isn't really intended to be a way for system components to describe 
  themselves to one another.  The registry might persist 
  component settings but it is not intended to be a publisher of settings.  
  For example: MicrosoftWord has a documented API by which you can learn of its 
  settings - you are not supposed to go poking through WindowsRegistry to learn 
  about word's settings. 
   
  Nevertheless, we'll run with this 
  example....
  ....if you were to look at distributed 
  systems that rely on WindowsRegistry to persist settings, you would find 
  that a single windows registry is not used to capture all settings 
  of the entire system.  If you were running in a 
  Windows environment, each of your distributed components (on separate 
  machines) would use their local windows registry 
  to manage their settings.  And, in a distributed 
  environment, there would not exist a single registry from which all 
  components exchange their configurations.   Component-A doesn't 
  learn about Component-B by means of a shared WindowsRegistry.   
  In windows (COM or DCOM), Component-A typically learns about Component-B's 
  settings... by directly interacting with Component-B's API. 
  
   
  (Note: Component-A learns about the 
  existence of  Component-B through another mechanism, which 
  we have referred to as a 'directory'.  'Directory' describes the 
  location of a component - it is not related 
  to 'policy'. )


- Some might think of DNS as an example of a 
consolidated set of rules.

  DNS is, in fact, an example of a directory of 
  other systems.  It provides a consolidated means to find other systems. 
  It does not represent a consolidated set of rules for interacting with 
  those systems.  It is little more than a list of 
  addresses.
- Some may refer to UDDI, 
for WebServices, as an example of consolidated rules.


  UDDI is an excellent example of how components might 
  publish their 'rules of engagement.   However, UDDI does not 
  represent the singleton approach.  
   
  UDDI  represents a singular access 
  point for finding or obtaining individual rules 
  (i.e. WSDLs - the syntactical rules of a 
  WebService).   A consumer still 
  asks the UDDI host for WSDLs, one by one.  The 
  WebService rules are *still* organized, and segregated, by the individual 
  WebServices.  
   
  (Truth be told, I feel that UDDI is a much better 
  example of the position I am advocating than as an example of the singleton 
  approach.)
 
I have further basis for my position on this 
issue.  I drafted a larger email illustrating 
how the singleton approach gets to be very difficult to 
implement once the system begins to incorporate multiple CourtRecordMDEs 
(court-1 and court-2 policy), or if the system begins to incorporate 
FilingAssembly queries...  
 

....but, for now, I'm going 
to pause here for feedback on this much:
 
Consider:
 
1) Do we agree that Policies are MDE-specific ( 
Such as MDE-query extensions/restrictions?  
)
 
2) If so, then, can we agree that Policies should then 
be organized by MDE (MDE-1's policies vs. MDE-2's 
policies)?
 
3) Can we agree that the proposed 'singleton' 
approach is inconsistent with other types of distributed multi-component 
systems?
 
 
If we can agree on that much, then why would we 
want to adopt the proposed 'singleton' 
approach?
 
If I left my position at this 
much:

   'MDE policies' is an approach that 
  is most consistent with other distributed system designs 
  (UDDI)....
   
  or , conversely,
   
  
   'PolicyMDE' is an approach that is 
  inconsistent with other distributed system 
  designs....
....then, is anyone able to disagree with that 
assessment?
...and/or, is anyone willing to 
provide an explanation of how the 'singleton' 
approach is still better and worthy of 
pursuit?
 
Will my dissenters please 
stand?
 
- Shane
LexisNexis
 
 





Follow-Ups:

Re: [legalxml-courtfiling] Policy MDE vs. MDE Policies
From: "Dallas Powell" <>








[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]