Hi Ernest.
I'm not certain that I understand what you've resolved here (i.e., that you think that
'name' COULD be used as an attribute or that you plan to use the 'name' attribute in
the future) ... but my own preference would be NOT to create a name attribute.
The design decision between attributes and elements is sometimes very contentious.
Some designers like attributes; and some like elements all the way down (and use
attributes for decorating elements with metadata of various sorts). For example, the
Health Language 7 ("HL7") CDA RIM is designed in this way.
There are some useful heuristics you can use in deciding on elements vs. attributes:
1. If the relevant data may be repeated (i.e., specified by '+' or '*'), then use an
element.
2. If the relevant data is further divided, use an element.
3. If the relevant data is a clearly defined data type (e.g., a date or integer) or
member of a limited enumeration, then consider using an attribute.
4. If you plan to reuse the relevant data, use an element (which can be decorated with
a unique identifier).
5. If you're using a DTD (and not XML-Schema) and you want to validate the structure
related to the relevant data, then use an element.
6. If you want to simplify parsing and search, use an element.
And then there's the consideration of consistency. A range of elements could be
represented with 'name' attributes:
facts (as in 'deffacts')
rules (as in 'defrule')
templates (as in 'deftemplate')
modules (as in 'defmodule')
Since XML representations are for data exchange and aren't intended for human
consumption, there's no reason whatsoever not to make your grammars simple and thereby
simplify parsing and search. Your all-elements approach seems quite reasonable from
this point of view.
Win
> I think Alan Moore wrote:
> >
> > <module>
> > <name>MAIN</name>
> > <rule>
> > <name>foo</name>
> > </rule>
> > </module>
> >
> > This is obviously more verbose and cumbersome for humans but might be better
> > suited to automation of various sorts (e.g. XSL transforms, DTD/Schema
> > validation, etc.) The content model of attributes is rather simple and not
> > very extensible.
> >
>
> Interesting. That's true. If you wanted to change "name" to have
> multiple parts, it's relatively easy if you've used elements, and hard
> if you've used attributes (indeed, if you've used attributes, you have
> to go to meta-meta data (i.e., information not represented in the XML
> itself) to learn how to parse the parts out; that's the current
> situation with the module::rulename names, so I think this is a good
> match to the current situation.
>
> In the present case, though, I think it's a very safe bet that rule
> names will never be anything but symbols. Module names could become
> scoped if modules are allowed to be nested -- but that actually could
> be done by nesting "module name='foo'" elements as well. So I think
> breaking the current rulename into a module name attribute and a rule
> name attribute fixes the problem.
>
>
> > Also, is there any pre-release documentation on the use of the
> > "single-slot-activation" feature?
>
> Download the software, and look in the release notes from the manual:
>
> The "slot-specific" declaration for templates. Deftemplate
> definitions can now include a "declare" section just as defrules
> can. There are several different properties that can be declared. One
> is "slot-specific". A template with this declaration will be matched
> in a special way: if a fact, created from such a template, which
> matches the left-hand-side of a rule is modified, the result depends
> on whether the modified slot is named in the pattern used to match the
> fact. As an example, consider the following:
>
> (deftemplate D (declare (slot-specific TRUE)) (slot A) (slot B))
>
> (defrule R
> ?d <- (D (A 1))
> =>
> (modify ?d (B 3)))
>
>
> Without the "slot-specific" declaration, this rule would enter an
> endless loop, because it modifies a fact matched on the LHS in such a
> way that the modified fact will still match. With the declaration, it
> can simply fire once. This behavior is actually what many new users
> expect as the default.
>
> And also:
>
> The "no-loop" declaration for rules. If you use (declare (no-loop
> TRUE)), then nothing that a rule does while firing can cause the
> immediate reactivation of the same rule; i.e., if a no-loop rule
> matches a fact, and the rule modifies that same fact such that the
> fact still matches, the rule will not be put back on the agenda,
> avoiding an infinite loop.
>
>
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Science and Engineering PSEs Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> PO Box 969, MS 9012 [EMAIL PROTECTED]
> Livermore, CA 94550 http://herzberg.ca.sandia.gov
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the list
> (use your own address!) List problems? Notify [EMAIL PROTECTED]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the list
(use your own address!) List problems? Notify [EMAIL PROTECTED]
--------------------------------------------------------------------
