I wrote a script to cross-check syschar schema against definitions
schema and found that there is good consistency. Whenever an object has
been deprecated and replaced with an enhanced version, the new elements
have been added to the original item.. eg fileeffectiverights53_object
superseded fileeffectiverights_object and trustee_sid was added to
fileeffectiverights_item without removing the original trustee_name.
This is the same way that texfilecontent and texfilecontent54 have been
handled and, given the bigger picture, this makes more sense and removes
my concern that there should be a texfilecontent54_item.
The only concern I have is that it is possible to write an item into
syschar that is schema valid but incorrect. Taking the example of the
fileeffectiverights, it is valid to include both a trustee_name and a
trustee_sid in the item but only one should be there depending on the
probe used. Perhaps the use of xsd:choice could limit the potential for
confusion?
One small inconsistency I noticed is that there an object and state
called inetlisteningservers but the item is called inetlisteningserver.
Regards // Martin
>-----Original Message-----
>From: Baker, Jon [mailto:
bakerj@...]
>Sent: Monday, July 07, 2008 7:24 PM
>To:
OVAL-DEVELOPER-LIST@...
>Subject: Re: [OVAL-DEVELOPER-LIST] Textfilecontent54 test without
>parentheses for subexpression
>
>I would prefer consistency in how objects, states, and items relate to
>each other. For the most part we are very consistent and we should
>strive to be. This consistency makes it easier for us all to understand
>the language, and for developers to build simplifying abstractions into
>their tools. Having element names that do not align in the sc schema
>and the definitions schema certainly forces more work into developing
>the OVAL Interpreter.
>
>
>Jon
>
>============================================
>Jonathan O. Baker
>The MITRE Corporation
>Email:
bakerj@...
>
>
>
>>-----Original Message-----
>>From: Buttner, Drew [mailto:
abuttner@...]
>>Sent: Monday, July 07, 2008 7:50 AM
>>To: oval-developer-list OVAL Developer List/Closed Public Discussion
>>Subject: Re: [OVAL-DEVELOPER-LIST] Textfilecontent54 test without
>>parentheses for subexpression
>>
>>>Additionally, the test is called textfilecontent54_test but the item
>>in
>>>SC is called textfilecontent_item - lacking the 54 designation and
>>>providing opportunities for confusion.
>>>I think the different entities of textfilecontent54 should not be
>>added
>>>to the original item and instead there should be a new
>>>textfilecontent54_.
>>
>>It would be great to hear other opinions on this. We did not create a
>>new item in the SC schema on purpose here. The thinking is that since
>>SC entities are optional, we don't need to create an entirely new
>item.
>>This keeps the SC schema from being cluttered by deprecated items.
>All
>>the textfilecontent tests would use the same item.
>>
>>Does this make sense? Would the community rather an strict 1:1
>mapping
>>here?
>>
>>Thanks
>>Drew
>>
>>To unsubscribe, send an email message to
LISTSERV@... with
>>SIGNOFF OVAL-DEVELOPER-LIST
>>in the BODY of the message. If you have difficulties, write to OVAL-
>>
DEVELOPER-LIST-request@....
>
>To unsubscribe, send an email message to
LISTSERV@... with
>SIGNOFF OVAL-DEVELOPER-LIST
>in the BODY of the message. If you have difficulties, write to OVAL-
>
DEVELOPER-LIST-request@....
To unsubscribe, send an email message to
LISTSERV@... with
SIGNOFF OVAL-DEVELOPER-LIST
in the BODY of the message. If you have difficulties, write to
OVAL-DEVELOPER-LIST-request@....
