win:process_item vs. win:process_object and win:process58_object

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

win:process_item vs. win:process_object and win:process58_object

lutton

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

joval
There's only one win-sc:process_item, which is the item corresponding to both objects.  It shouldn't matter how you got it.

On 10/16/2012 11:17 AM, Bill Lutton wrote:

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

lutton

Thanks David, that makes sense.

I’m new to OVAL, so apologies in advance if this is a silly question…

 

Given that the process_object is intended to return those additional elements, does the process_state need to be updated to allow them to be tested?  More specifically, how can a def be written that could tell if those addition elements were supplied by a process_object?

 

Thanks again,

Bill L.

 

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 10:44 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Bill Lutton
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

There's only one win-sc:process_item, which is the item corresponding to both objects.  It shouldn't matter how you got it.

On 10/16/2012 11:17 AM, Bill Lutton wrote:

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

Danny Haynes
Administrator
In reply to this post by lutton

Hi Bill,

 

Good question!

 

As you mentioned, the win-def:process_object and win-def:process58_object share the same win-sc:process_item.  Also, all item entities are optional (minOccurs=”0”). 

 

With that in mind, a tool that supports the win-def:process_object could collect this information even though you could not check it with the win-def:process_state.  This assumes that you are working with OVAL 5.8 or later.  At the same time, you could just as easily not collect it and that would be fine too (i.e. they are optional).  

 

The only problem to point out if you decide to collect the extra entities, with the win-def:process_object, is that it would hurt the portability of the content.  That is, the win-sc:process_items would not be portable to tools that support versions before OVAL 5.8 because those extra entities do not exist in the earlier versions of the schema.

 

Thanks,

Danny

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Tuesday, October 16, 2012 12:17 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

Danny Haynes
Administrator
In reply to this post by lutton

Hi Bill,


The win-def:process_state does not need to be updated to support the new entities.  If you would like to check those entities, the win-def:process58_state should be used because the win-def:process_state is deprecated.  When a construct is deprecated, its use is discouraged although perfectly acceptable until it is removed from the language.

 

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

Thanks,

Danny

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Tuesday, October 16, 2012 12:57 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Thanks David, that makes sense.

I’m new to OVAL, so apologies in advance if this is a silly question…

 

Given that the process_object is intended to return those additional elements, does the process_state need to be updated to allow them to be tested?  More specifically, how can a def be written that could tell if those addition elements were supplied by a process_object?

 

Thanks again,

Bill L.

 

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 10:44 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Bill Lutton
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

There's only one win-sc:process_item, which is the item corresponding to both objects.  It shouldn't matter how you got it.

On 10/16/2012 11:17 AM, Bill Lutton wrote:

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

joval
In reply to this post by lutton
The definition would would have to use a process58_test, and hence employ a process58_state and process58_object.

It's always a little weird when they (MITRE) change an OVAL object, but don't introduce a new item for it.

On 10/16/2012 11:56 AM, Bill Lutton wrote:

Thanks David, that makes sense.

I’m new to OVAL, so apologies in advance if this is a silly question…

 

Given that the process_object is intended to return those additional elements, does the process_state need to be updated to allow them to be tested?  More specifically, how can a def be written that could tell if those addition elements were supplied by a process_object?

 

Thanks again,

Bill L.

 

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 10:44 AM
To: OVAL Developer List (Closed Public Discussion)
Cc: Bill Lutton
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

There's only one win-sc:process_item, which is the item corresponding to both objects.  It shouldn't matter how you got it.

On 10/16/2012 11:17 AM, Bill Lutton wrote:

Hi there,

 

In 5.10 vs 5.9, the win:process_item lists 3 additional child elements (creation_time, dep_enabled, primary_window_text).  In 5.10.1 win:process_state vs win:process58_state, it looks like these 3 elements might be intended to be collected for only win:process58_objects.  Is it intended that a win:process_object should also collect these 3 additional elements?

 

Thanks in advance,

Bill L.

 

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

joval
In reply to this post by Danny Haynes
Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:
Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

Danny Haynes
Administrator

Hi David,

 

That’s a good point, you could do that.

 

Bill, is there a specific reason why you need to determine if the items collected by a process_object have the extra entities?  I guess I am wondering why you couldn’t just use the win-def:process58_object.

 

Thanks,

Danny   

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 1:26 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

lutton

Actually, I don’t have a reason to test an item from a process_object for the extra entities.  I’m implementing an SC generator and was interested in whether my process_object needed to return the extra items to be ‘correct’.  I thought that if there was no way to tell if I did or not, then I would not need to return those entities for process_object (I had not thought of David’s example).

 

However, I think the point you made about compatibility suggests that the ‘best’ implementation is to not report the extra entities for process_object.  Do I have that correct?

 

Thanks,

Bill L.

 

 

From: Haynes, Dan [mailto:[hidden email]]
Sent: Tuesday, October 16, 2012 12:12 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Hi David,

 

That’s a good point, you could do that.

 

Bill, is there a specific reason why you need to determine if the items collected by a process_object have the extra entities?  I guess I am wondering why you couldn’t just use the win-def:process58_object.

 

Thanks,

Danny   

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 1:26 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

Danny Haynes
Administrator

Hi Bill,

 

Yes, since item entities are optional, your SC producer will be correct if you do not collect the extra entities.

 

Yes, for the process_object, I would say it is probably best if you do not include the extra entities.  This will make your system-characteristics files usable by tools that support OVAL 5.0 or greater. 

 

If you need to collect the extra entities, you can just use the process58_object and mark your system-characteristics file as requiring OVAL 5.8 or later with the schema_version in the generator construct.

 

Does that seem like a reasonable approach?  Are there any concerns with this approach?

 

Thanks,

Danny

 

 

From: Bill Lutton [mailto:[hidden email]]
Sent: Tuesday, October 16, 2012 3:04 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, I don’t have a reason to test an item from a process_object for the extra entities.  I’m implementing an SC generator and was interested in whether my process_object needed to return the extra items to be ‘correct’.  I thought that if there was no way to tell if I did or not, then I would not need to return those entities for process_object (I had not thought of David’s example).

 

However, I think the point you made about compatibility suggests that the ‘best’ implementation is to not report the extra entities for process_object.  Do I have that correct?

 

Thanks,

Bill L.

 

 

From: Haynes, Dan [[hidden email]]
Sent: Tuesday, October 16, 2012 12:12 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Hi David,

 

That’s a good point, you could do that.

 

Bill, is there a specific reason why you need to determine if the items collected by a process_object have the extra entities?  I guess I am wondering why you couldn’t just use the win-def:process58_object.

 

Thanks,

Danny   

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 1:26 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].
Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

joval
I think, if you need output to be processed in a specific version of OVAL, then output that version of OVAL!  A product that requires 5.8 results should actually choke on 5.10.1 results.  Since the OVAL version is specified in the s-c document (/oval_system_characteristics/generator/oval:schema_version), there is simply no issue to worry about here.

So, no, I don't think that's an approach anyone should be peddling.  Instead, just be explicit about what version(s) of the schema you are supporting.

On 10/16/2012 2:25 PM, Haynes, Dan wrote:

Hi Bill,

 

Yes, since item entities are optional, your SC producer will be correct if you do not collect the extra entities.

 

Yes, for the process_object, I would say it is probably best if you do not include the extra entities.  This will make your system-characteristics files usable by tools that support OVAL 5.0 or greater. 

 

If you need to collect the extra entities, you can just use the process58_object and mark your system-characteristics file as requiring OVAL 5.8 or later with the schema_version in the generator construct.

 

Does that seem like a reasonable approach?  Are there any concerns with this approach?

 

Thanks,

Danny

 

 

From: Bill Lutton [[hidden email]]
Sent: Tuesday, October 16, 2012 3:04 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, I don’t have a reason to test an item from a process_object for the extra entities.  I’m implementing an SC generator and was interested in whether my process_object needed to return the extra items to be ‘correct’.  I thought that if there was no way to tell if I did or not, then I would not need to return those entities for process_object (I had not thought of David’s example).

 

However, I think the point you made about compatibility suggests that the ‘best’ implementation is to not report the extra entities for process_object.  Do I have that correct?

 

Thanks,

Bill L.

 

 

From: Haynes, Dan [[hidden email]]
Sent: Tuesday, October 16, 2012 12:12 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Hi David,

 

That’s a good point, you could do that.

 

Bill, is there a specific reason why you need to determine if the items collected by a process_object have the extra entities?  I guess I am wondering why you couldn’t just use the win-def:process58_object.

 

Thanks,

Danny   

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 1:26 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].


--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

Reply | Threaded
Open this post in threaded view
|

Re: win:process_item vs. win:process_object and win:process58_object

Danny Haynes
Administrator

Hi David,

I agree that if a product requires OVAL 5.8 content and you give it OVAL 5.10.1 content it should fail.  I also agree that the schema_version, in the generator, should be used to explicitly specify the version of OVAL because it provides tools with a way to determine if they support the content.  This all aligns with how the OVAL specification is written.

When recommending this approach, I was thinking in the context that users should be able to plug-and-play their OVAL-capable tools since they are interoperable and tool vendors will not necessarily know what tools their tool will be interoperating with and that by producing “least versioned” content it would help improve its usability in other tools.  I should have been more explicit about that in my previous message.

 

For example, consider an sc producer that supports OVAL 5.10.1 and a definition evaluator that supports OVAL 5.4.  If the sc producer always outputs it content as OVAL 5.10.1, the definition evaluator may see that and say it cannot support the content even if it only uses process_test which hasn’t changed since OVAL 5.0.

 

The “least version principle” can be used to maximize the chances that the content produced by one tool is usable in other tools.  The “least version principle” is the process of producing content at the earliest version of OVAL that it will validate.  Using the above example, the sc producer could output its sc file as OVAL 5.0, rather than 5.10.1, because the process_test hasn’t changed since then and the content will validate.  As a result, the content would now usable by the definition evaluator which only supports 5.4.  We take a similar approach with the OVAL Repository content and provide content downloads ranging from version 5.3 to 5.10.

 

Of course, this is not a requirement and a tool developer is in no way required to use the “least version principle”, but, doing so helps improve the usability of the content.

                                                                                                                                                                                          

Thanks,

Danny

 

From: David Solin [mailto:[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 3:36 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

I think, if you need output to be processed in a specific version of OVAL, then output that version of OVAL!  A product that requires 5.8 results should actually choke on 5.10.1 results.  Since the OVAL version is specified in the s-c document (/oval_system_characteristics/generator/oval:schema_version), there is simply no issue to worry about here.

So, no, I don't think that's an approach anyone should be peddling.  Instead, just be explicit about what version(s) of the schema you are supporting.

On 10/16/2012 2:25 PM, Haynes, Dan wrote:

Hi Bill,

 

Yes, since item entities are optional, your SC producer will be correct if you do not collect the extra entities.

 

Yes, for the process_object, I would say it is probably best if you do not include the extra entities.  This will make your system-characteristics files usable by tools that support OVAL 5.0 or greater. 

 

If you need to collect the extra entities, you can just use the process58_object and mark your system-characteristics file as requiring OVAL 5.8 or later with the schema_version in the generator construct.

 

Does that seem like a reasonable approach?  Are there any concerns with this approach?

 

Thanks,

Danny

 

 

From: Bill Lutton [[hidden email]]
Sent: Tuesday, October 16, 2012 3:04 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, I don’t have a reason to test an item from a process_object for the extra entities.  I’m implementing an SC generator and was interested in whether my process_object needed to return the extra items to be ‘correct’.  I thought that if there was no way to tell if I did or not, then I would not need to return those entities for process_object (I had not thought of David’s example).

 

However, I think the point you made about compatibility suggests that the ‘best’ implementation is to not report the extra entities for process_object.  Do I have that correct?

 

Thanks,

Bill L.

 

 

From: Haynes, Dan [[hidden email]]
Sent: Tuesday, October 16, 2012 12:12 PM
To: [hidden email]
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Hi David,

 

That’s a good point, you could do that.

 

Bill, is there a specific reason why you need to determine if the items collected by a process_object have the extra entities?  I guess I am wondering why you couldn’t just use the win-def:process58_object.

 

Thanks,

Danny   

 

From: David Solin [[hidden email]] On Behalf Of David Solin
Sent: Tuesday, October 16, 2012 1:26 PM
To: oval-developer-list OVAL Developer List/Closed Public Discussion
Cc: Haynes, Dan
Subject: Re: [OVAL-DEVELOPER-LIST] win:process_item vs. win:process_object and win:process58_object

 

Actually, one could use a variable_object pointing to a local_variable ObjectComponent, and reference the field directly... though I can't imagine why!

On 10/16/2012 12:17 PM, Haynes, Dan wrote:

Unfortunately, I don’t think you can write a definition to tell if the additional entities were supplied by a win-def:process_object.

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].

 

--

jOVAL.org: OVAL implemented in Java.
Scan any machine from any machine. For free!
Learn More | Features | Download

To unsubscribe, send an email message to [hidden email] with SIGNOFF OVAL-DEVELOPER-LIST in the BODY of the message. If you have difficulties, write to [hidden email].