|-----Original Message-----
|From: Yakov Shafranovich [mailto:research(_at_)solidmatrix(_dot_)com]
|Sent: Tuesday, August 19, 2003 11:38 AM
<snip>
|
|Since this format is in XML can we leverage XML-related
|technologies such
|as XInclude, XPath, XSLT, etc. Some of them can prove to be
|very useful -
|for example XInclude can be used to combine policies, XLinks
|can be used to
|refer to specific elements within policies, etc.
I had intuitively hedged away from these when I was working on the
examples. After your note I did some research to figure out what my
intuition was telling me.
XInclude, XPath, and XSLT provide some mechanisms for including external
XML. Their use is a little bit convoluted (but not much) for simple
includes, but I think their use in the more common CPD sharing
application may be very complex when compared to a CPD specific
protocol.
There are two drawbacks that I see and one benefit.
The drawbacks are that CPD element sharing tends to require a complex
mix of sharing rules and transforms as a rule. Specifically that one
SYSTEM in a CPD network will share portions of it's CPD and import
portions of it's CPD in very specific ways.
The raw XML components tend to primarily focus on the inclusion of whole
documents. There are some provisions for the kind of complex sharing
mechanisms we require, for example XLink allows for application specific
parsing, however the implementation is a bit confusing (I may need
coaching).
The benefit... XInclude seems to work just fine when a wholesale import
is required, and may be a preferred mechanism for those cases. In
general there is no reason that XInclude, and in fact any of the XML
mechanisms can't be implemented - though I think they may be of limited
use in this application. (An XML expert may prove me wrong here!)
I would recommend that if these elements are implemented they should
probably be limited to the manipulation of a SYSTEMs local CPD - but if
someone can recommend some pure XML based implementations of sharing
partial documents between SYSTEMs then we should include those examples
for reference and compare the results.
I will make an example of XInclude to go along with the current local
IMPORT example. Other examples such as XLink are a bit beyond me right
now - if an XML guru is willing to construct some examples I will
include them.
---
I will try to clarify the requirements -
In the purest sense, a CPD that can inherit or export portions if itself
becomes part of a network. In the example document, each node on the
network is identified as a SYSTEM.
Each SYSTEM must control which parts of it's local CPD are imported and
exported, and must also control any translations that occur.
(XLink should be able to do this because it explicitly states that
parsing happens at the application level).
It appears that the majority of decisions used to define and execute
sharing transactions can be described in a few finite terms - but
perhaps with complex consequences. As such it seems to me that in order
to keep the complexity of the system down we can define a simplified
interface with specific expectations. The elements that describe these
can be CPDL specific structures that encapsulate this functionality
rather than xml structures that are extended to meet this functionality.
The framework so far seems to require mechanisms for:
Defining elements or groups of elements that can be exported, and can be
named for that purpose. (Use GROUP).
Defining elements or groups of elements that can be imported and reused.
(Use the IMPORT side of GROUP).
Defining the translation of elements or groups of elements upon import.
(Use IMPORT parameters. Careful placement of IMPORT within internal
GROUPs - in this case the internal GROUP creates a "wrapper" around the
import thereby effecting the translation).
Defining merge specification to resolve conflicts with local policy
elements and provide mechanisms for aggregating incoming policy elements
when necessary. (Use ALLOW-IMPORT using "weight" and "aggregation"
coupled with IMPORT "aggregation" to define placement and translation.
Other mechanisms still needed, but likely to fit within this framework.)
Defining security constraints for the import and export of policy
elements. (Use ALLOW-IMPORT and ALLOW-EXPORT in conjunction with SYSTEM
to define the connections of the CPD network elements and the
constraints on those connections.)
Comments?
_M
PS: Perhaps "location" attributes should be constrained to "href" ?
Should <IMPORT file="/etc/CPDL..." />
become <IMPORT href="file://etc/CPDL..." />
I think yes unless I get other comments.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg