Referencing definitions in an external file/repository
|
|
Andrew Buttner
|
One of the topics discussed at OVAL Developer Days was developing a way
for definitions to reference another definition (think about the <extend_definition> element) without having to include copy of the definition in the file. For example, a definition might want to leverage an inventory definition that exists in the primary source vendor's repository. In version 5, in order for the OVAL Definition file to validate, that inventory definition would have to be copied from that vendor's repository. Note that the schema has a key_ref that enforces that any id given in the 'definition_ref' attribute is found in the document. If this key_ref was just removed and it was not required to include these extended definitions, there would be no way for a tool to know where to find the definition being referenced. <extend_definition definition_ref="" negate="" comment="" /> The idea is that it might be easier to just point to that definition instead of including it. Granted, we will still want to allow the copying method if desired. I've given this some thought and would like to propose the following solutions for comment ... ============================================== 1 - link an OVAL id namespace to repository ============================================== The first option is to use the namespace portion of the oval id to identify the repository where the content can be found. A master list would be kept and new repositories (that wanted to share content) would register their namespace with OVAL. We could then remove the key_ref and put the onus on the tool for find the definition by looking up the repository location via the id namespace. The unknown result could be used when an external definition can not be found. The biggest issue with this approach is that it puts the party in charge of registering repositories "in the loop". When we worked on the oval id format, one of the main desires was that we didn't want organizations to have to rely on a 3rd party to produce content. (what happens when that 3rd party doesn't move fast enough, or at all?) Hence the namespace portion of the ID. The proposal above would go against this. Granted, registering a small (right now) number of repositories would be easier and registering every id that is produced (this was our main concern). ============================================== 2 - repository_ref attribute ============================================== <extend_definition repository_ref="" definition_ref="" negate="" comment="" /> The addition of the 'repository_ref' attribute would enable a content writer to state where to find the definition being extended. This could be a URL to a repository, or maybe a file, etc. If just a top level repository URL, a tool would then have to figure out how to get the actual xml fee from it. This idea would probably only work as a URL to an xml doc. We will have to guard against URLs that change/disappear. ============================================== 3 - <external_definition> ============================================== The third proposal is really just another point to think about and is something that could be combined with one of the other proposals. Should we create a new element called <external_definition> to use for references to definitions not found in the current document. We would keep the <extened_definition> element the same and use it only for definitions that are found locally. I'm interested to hear everyone's thoughts on this matter. I guess in short, do you like the idea of a global repository map or do you think providing a URL would be more appropriate? The other pieces to this puzzle that will be addressed separately is the need for guidelines related to external repositories so that they offer up the expected content and in a known way Thanks Drew --------- Andrew Buttner The MITRE Corporation abuttner@... 781-271-3515 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@.... |
|||||||||||||||
Ken Lassesen-3
|
I am inclined towards:
<extend_definition repository_file="" repository_href="" repository_soa="" definition_ref="" negate="" comment="" /> Where * repository_file="" -- indicates the file (typically co-located in the same folder), this handles the isolated machine scenario * repository_href -- indicates a web location to download from, http, ftp should be supported at least, * repository_soa="" indicates that a web services is available, i.e. string GetDefinitionXmlString(string definition_ref) which will return the explicit elements needed for this definition (MITRE repository can likely support this with little effort). BOTH of the following may be given (so we can support compression) repository_file="my-Oval-xml" repository_href="http://reddwarfdogs.com/oval.zip" Ken -----Original Message----- From: Buttner, Drew [mailto:abuttner@...] Sent: Monday, July 14, 2008 6:18 AM To: OVAL-DEVELOPER-LIST@... Subject: [OVAL-DEVELOPER-LIST] Referencing definitions in an external file/repository One of the topics discussed at OVAL Developer Days was developing a way for definitions to reference another definition (think about the <extend_definition> element) without having to include copy of the definition in the file. For example, a definition might want to leverage an inventory definition that exists in the primary source vendor's repository. In version 5, in order for the OVAL Definition file to validate, that inventory definition would have to be copied from that vendor's repository. Note that the schema has a key_ref that enforces that any id given in the 'definition_ref' attribute is found in the document. If this key_ref was just removed and it was not required to include these extended definitions, there would be no way for a tool to know where to find the definition being referenced. <extend_definition definition_ref="" negate="" comment="" /> The idea is that it might be easier to just point to that definition instead of including it. Granted, we will still want to allow the copying method if desired. I've given this some thought and would like to propose the following solutions for comment ... ============================================== 1 - link an OVAL id namespace to repository ============================================== The first option is to use the namespace portion of the oval id to identify the repository where the content can be found. A master list would be kept and new repositories (that wanted to share content) would register their namespace with OVAL. We could then remove the key_ref and put the onus on the tool for find the definition by looking up the repository location via the id namespace. The unknown result could be used when an external definition can not be found. The biggest issue with this approach is that it puts the party in charge of registering repositories "in the loop". When we worked on the oval id format, one of the main desires was that we didn't want organizations to have to rely on a 3rd party to produce content. (what happens when that 3rd party doesn't move fast enough, or at all?) Hence the namespace portion of the ID. The proposal above would go against this. Granted, registering a small (right now) number of repositories would be easier and registering every id that is produced (this was our main concern). ============================================== 2 - repository_ref attribute ============================================== <extend_definition repository_ref="" definition_ref="" negate="" comment="" /> The addition of the 'repository_ref' attribute would enable a content writer to state where to find the definition being extended. This could be a URL to a repository, or maybe a file, etc. If just a top level repository URL, a tool would then have to figure out how to get the actual xml fee from it. This idea would probably only work as a URL to an xml doc. We will have to guard against URLs that change/disappear. ============================================== 3 - <external_definition> ============================================== The third proposal is really just another point to think about and is something that could be combined with one of the other proposals. Should we create a new element called <external_definition> to use for references to definitions not found in the current document. We would keep the <extened_definition> element the same and use it only for definitions that are found locally. I'm interested to hear everyone's thoughts on this matter. I guess in short, do you like the idea of a global repository map or do you think providing a URL would be more appropriate? The other pieces to this puzzle that will be addressed separately is the need for guidelines related to external repositories so that they offer up the expected content and in a known way Thanks Drew --------- Andrew Buttner The MITRE Corporation abuttner@... 781-271-3515 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@.... |
|||||||||||||||
Dick Whitehurst (McAfee, Plano, TX)
|
Drew,
Since the ids are defined to be globally unique, I am opposed to including information about their location into the language, except, perhaps, as a hint, similar to the way schemaloc works for xml schema validation. The OVAL processor should be allowed to use whatever mechanism it chooses to locate the referenced definition(s). Dick Whitehurst -----Original Message----- From: Buttner, Drew [mailto:abuttner@...] Sent: Monday, July 14, 2008 8:18 AM To: OVAL-DEVELOPER-LIST@... Subject: [OVAL-DEVELOPER-LIST] Referencing definitions in an external file/repository One of the topics discussed at OVAL Developer Days was developing a way for definitions to reference another definition (think about the <extend_definition> element) without having to include copy of the definition in the file. For example, a definition might want to leverage an inventory definition that exists in the primary source vendor's repository. In version 5, in order for the OVAL Definition file to validate, that inventory definition would have to be copied from that vendor's repository. Note that the schema has a key_ref that enforces that any id given in the 'definition_ref' attribute is found in the document. If this key_ref was just removed and it was not required to include these extended definitions, there would be no way for a tool to know where to find the definition being referenced. <extend_definition definition_ref="" negate="" comment="" /> The idea is that it might be easier to just point to that definition instead of including it. Granted, we will still want to allow the copying method if desired. I've given this some thought and would like to propose the following solutions for comment ... ============================================== 1 - link an OVAL id namespace to repository ============================================== The first option is to use the namespace portion of the oval id to identify the repository where the content can be found. A master list would be kept and new repositories (that wanted to share content) would register their namespace with OVAL. We could then remove the key_ref and put the onus on the tool for find the definition by looking up the repository location via the id namespace. The unknown result could be used when an external definition can not be found. The biggest issue with this approach is that it puts the party in charge of registering repositories "in the loop". When we worked on the oval id format, one of the main desires was that we didn't want organizations to have to rely on a 3rd party to produce content. (what happens when that 3rd party doesn't move fast enough, or at all?) Hence the namespace portion of the ID. The proposal above would go against this. Granted, registering a small (right now) number of repositories would be easier and registering every id that is produced (this was our main concern). ============================================== 2 - repository_ref attribute ============================================== <extend_definition repository_ref="" definition_ref="" negate="" comment="" /> The addition of the 'repository_ref' attribute would enable a content writer to state where to find the definition being extended. This could be a URL to a repository, or maybe a file, etc. If just a top level repository URL, a tool would then have to figure out how to get the actual xml fee from it. This idea would probably only work as a URL to an xml doc. We will have to guard against URLs that change/disappear. ============================================== 3 - <external_definition> ============================================== The third proposal is really just another point to think about and is something that could be combined with one of the other proposals. Should we create a new element called <external_definition> to use for references to definitions not found in the current document. We would keep the <extened_definition> element the same and use it only for definitions that are found locally. I'm interested to hear everyone's thoughts on this matter. I guess in short, do you like the idea of a global repository map or do you think providing a URL would be more appropriate? The other pieces to this puzzle that will be addressed separately is the need for guidelines related to external repositories so that they offer up the expected content and in a known way Thanks Drew --------- Andrew Buttner The MITRE Corporation abuttner@... 781-271-3515 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@.... |
|||||||||||||||
Thomas R. Jones
|
Why are we not leveraging preexisting, community accepted and
developed technologies, such as XML Inclusions(XInclude)? It will provide all the neccessary requirements for oval to remotely query and parse data sets. Its implements URL escaping, so that we don't have to. It already has a failure mechanism, xi:fallback, that can be custom altered according to schema standard(and/or developer preference). Automatically, disallows href link fragments. I.e. Everything after # And provides any and all resources available to the application that is in accordance with the URL standard. Thusly, new and existing URL schemes will automatically be accepted. Validating parsers are compatible and should be able to validate the entire document set(to include remote data) as one entity. No new namespace declaration needed. No global repository needed. Comments? Sent from my iPhone On Jul 14, 2008, at 8:18 AM, "Buttner, Drew" <abuttner@...> wrote: > One of the topics discussed at OVAL Developer Days was developing a > way > for definitions to reference another definition (think about the > <extend_definition> element) without having to include copy of the > definition in the file. For example, a definition might want to > leverage an inventory definition that exists in the primary source > vendor's repository. In version 5, in order for the OVAL Definition > file to validate, that inventory definition would have to be copied > from that vendor's repository. Note that the schema has a key_ref > that > enforces that any id given in the 'definition_ref' attribute is found > in the document. If this key_ref was just removed and it was not > required to include these extended definitions, there would be no way > for a tool to know where to find the definition being referenced. > > <extend_definition definition_ref="" > negate="" > comment="" /> > > The idea is that it might be easier to just point to that definition > instead of including it. Granted, we will still want to allow the > copying method if desired. I've given this some thought and would > like > to propose the following solutions for comment ... > > ============================================== > 1 - link an OVAL id namespace to repository > ============================================== > > The first option is to use the namespace portion of the oval id to > identify the repository where the content can be found. A master list > would be kept and new repositories (that wanted to share content) > would > register their namespace with OVAL. We could then remove the key_ref > and put the onus on the tool for find the definition by looking up the > repository location via the id namespace. The unknown result could be > used when an external definition can not be found. > > The biggest issue with this approach is that it puts the party in > charge of registering repositories "in the loop". When we worked on > the oval id format, one of the main desires was that we didn't want > organizations to have to rely on a 3rd party to produce content. > (what > happens when that 3rd party doesn't move fast enough, or at all?) > Hence the namespace portion of the ID. The proposal above would go > against this. Granted, registering a small (right now) number of > repositories would be easier and registering every id that is produced > (this was our main concern). > > ============================================== > 2 - repository_ref attribute > ============================================== > > <extend_definition repository_ref="" > definition_ref="" > negate="" > comment="" /> > > The addition of the 'repository_ref' attribute would enable a content > writer to state where to find the definition being extended. This > could be a URL to a repository, or maybe a file, etc. If just a top > level repository URL, a tool would then have to figure out how to get > the actual xml fee from it. This idea would probably only work as a > URL to an xml doc. We will have to guard against URLs that > change/disappear. > > ============================================== > 3 - <external_definition> > ============================================== > > The third proposal is really just another point to think about and is > something that could be combined with one of the other proposals. > Should we create a new element called <external_definition> to use for > references to definitions not found in the current document. We would > keep the <extened_definition> element the same and use it only for > definitions that are found locally. > > > I'm interested to hear everyone's thoughts on this matter. I guess in > short, do you like the idea of a global repository map or do you think > providing a URL would be more appropriate? > > The other pieces to this puzzle that will be addressed separately is > the need for guidelines related to external repositories so that they > offer up the expected content and in a known way > > Thanks > Drew > > --------- > > Andrew Buttner > The MITRE Corporation > abuttner@... > 781-271-3515 > > 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@.... |
|||||||||||||||
|
Andrew Buttner
|
I am all for using accepted technologies like XInclude if we can, but
one technical problem to overcome with this is that we can't just include an entire OVAL doc in one place. What needs to be included is a definition, plus any necessary tests (which need to go in the tests section), plus any objects (which need to go in the objects section), etc. I think we would have to change the way OVAL is structured to make this work. Rather than inclusion, I think what we really need is a way to say: instead of looking in this current OVAL doc, look over there for the information. Agree? Thanks Drew >-----Original Message----- >From: Thomas R. Jones [mailto:thomas.jones@...] >Sent: Tuesday, July 15, 2008 1:59 PM >To: oval-developer-list OVAL Developer List/Closed Public Discussion >Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an >external file/repository > >Why are we not leveraging preexisting, community accepted and >developed technologies, such as XML Inclusions(XInclude)? > >It will provide all the neccessary requirements for oval to remotely >query and parse data sets. Its implements URL escaping, so that we >don't have to. It already has a failure mechanism, xi:fallback, that >can be custom altered according to schema standard(and/or developer >preference). > >Automatically, disallows href link fragments. I.e. Everything after # > >And provides any and all resources available to the application that >is in accordance with the URL standard. Thusly, new and existing URL >schemes will automatically be accepted. > >Validating parsers are compatible and should be able to validate the >entire document set(to include remote data) as one entity. > >No new namespace declaration needed. No global repository needed. > >Comments? > >Sent from my iPhone > >On Jul 14, 2008, at 8:18 AM, "Buttner, Drew" <abuttner@...> > >> One of the topics discussed at OVAL Developer Days was developing a >> way >> for definitions to reference another definition (think about the >> <extend_definition> element) without having to include copy of the >> definition in the file. For example, a definition might want to >> leverage an inventory definition that exists in the primary source >> vendor's repository. In version 5, in order for the OVAL Definition >> file to validate, that inventory definition would have to be copied >> from that vendor's repository. Note that the schema has a key_ref >> that >> enforces that any id given in the 'definition_ref' attribute is >> in the document. If this key_ref was just removed and it was not >> required to include these extended definitions, there would be no way >> for a tool to know where to find the definition being referenced. >> >> <extend_definition definition_ref="" >> negate="" >> comment="" /> >> >> The idea is that it might be easier to just point to that definition >> instead of including it. Granted, we will still want to allow the >> copying method if desired. I've given this some thought and would >> like >> to propose the following solutions for comment ... >> >> ============================================== >> 1 - link an OVAL id namespace to repository >> ============================================== >> >> The first option is to use the namespace portion of the oval id to >> identify the repository where the content can be found. A master >> would be kept and new repositories (that wanted to share content) >> would >> register their namespace with OVAL. We could then remove the key_ref >> and put the onus on the tool for find the definition by looking up the >> repository location via the id namespace. The unknown result could be >> used when an external definition can not be found. >> >> The biggest issue with this approach is that it puts the party in >> charge of registering repositories "in the loop". When we worked on >> the oval id format, one of the main desires was that we didn't want >> organizations to have to rely on a 3rd party to produce content. >> (what >> happens when that 3rd party doesn't move fast enough, or at all?) >> Hence the namespace portion of the ID. The proposal above would go >> against this. Granted, registering a small (right now) number of >> repositories would be easier and registering every id that is >> (this was our main concern). >> >> ============================================== >> 2 - repository_ref attribute >> ============================================== >> >> <extend_definition repository_ref="" >> definition_ref="" >> negate="" >> comment="" /> >> >> The addition of the 'repository_ref' attribute would enable a >> writer to state where to find the definition being extended. This >> could be a URL to a repository, or maybe a file, etc. If just a top >> level repository URL, a tool would then have to figure out how to get >> the actual xml fee from it. This idea would probably only work as a >> URL to an xml doc. We will have to guard against URLs that >> change/disappear. >> >> ============================================== >> 3 - <external_definition> >> ============================================== >> >> The third proposal is really just another point to think about and is >> something that could be combined with one of the other proposals. >> Should we create a new element called <external_definition> to use for >> references to definitions not found in the current document. We would >> keep the <extened_definition> element the same and use it only for >> definitions that are found locally. >> >> >> I'm interested to hear everyone's thoughts on this matter. I guess in >> short, do you like the idea of a global repository map or do you think >> providing a URL would be more appropriate? >> >> The other pieces to this puzzle that will be addressed separately is >> the need for guidelines related to external repositories so that they >> offer up the expected content and in a known way >> >> Thanks >> Drew >> >> --------- >> >> Andrew Buttner >> The MITRE Corporation >> abuttner@... >> 781-271-3515 >> >> To unsubscribe, send an email message to LISTSERV@... >> 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@.... |
|||||||||||||||
|
Thomas R. Jones
|
Ahhhh. I see the issue. It is still available through standardized
technologies through the following: My crude example <xi:include href="http://www.domain.com/remote_file.xml" xpointer="element(oval_definitions/definitions/definition)"/> Or possibly if their are more than one definition contained within the remote resource; all within the href attribute as: "http://www.domain.com/remote_file.xml#xpointer(id(oval:org.mitre.oval:def:number " This explicitly declares that the entire element with that given id located within the specified remote file is to be included in its entirety to include attributes. Thusly, at any given point we may implement an entire document data set.....or as you pointed out....specify data fragments at a given position in which they are relevant. Thomas Sent from my iPhone On Jul 15, 2008, at 2:05 PM, "Buttner, Drew" <abuttner@...> wrote: > I am all for using accepted technologies like XInclude if we can, but > one technical problem to overcome with this is that we can't just > include an entire OVAL doc in one place. What needs to be included is > a definition, plus any necessary tests (which need to go in the tests > section), plus any objects (which need to go in the objects section), > etc. I think we would have to change the way OVAL is structured to > make this work. > > Rather than inclusion, I think what we really need is a way to say: > instead of looking in this current OVAL doc, look over there for the > information. > > Agree? > > Thanks > Drew > > > >> -----Original Message----- >> From: Thomas R. Jones [mailto:thomas.jones@...] >> Sent: Tuesday, July 15, 2008 1:59 PM >> To: oval-developer-list OVAL Developer List/Closed Public Discussion >> Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an >> external file/repository >> >> Why are we not leveraging preexisting, community accepted and >> developed technologies, such as XML Inclusions(XInclude)? >> >> It will provide all the neccessary requirements for oval to remotely >> query and parse data sets. Its implements URL escaping, so that we >> don't have to. It already has a failure mechanism, xi:fallback, that >> can be custom altered according to schema standard(and/or developer >> preference). >> >> Automatically, disallows href link fragments. I.e. Everything after # >> >> And provides any and all resources available to the application that >> is in accordance with the URL standard. Thusly, new and existing URL >> schemes will automatically be accepted. >> >> Validating parsers are compatible and should be able to validate the >> entire document set(to include remote data) as one entity. >> >> No new namespace declaration needed. No global repository needed. >> >> Comments? >> >> Sent from my iPhone >> >> On Jul 14, 2008, at 8:18 AM, "Buttner, Drew" <abuttner@...> > wrote: >> >>> One of the topics discussed at OVAL Developer Days was developing a >>> way >>> for definitions to reference another definition (think about the >>> <extend_definition> element) without having to include copy of the >>> definition in the file. For example, a definition might want to >>> leverage an inventory definition that exists in the primary source >>> vendor's repository. In version 5, in order for the OVAL Definition >>> file to validate, that inventory definition would have to be copied >>> from that vendor's repository. Note that the schema has a key_ref >>> that >>> enforces that any id given in the 'definition_ref' attribute is > found >>> in the document. If this key_ref was just removed and it was not >>> required to include these extended definitions, there would be no > way >>> for a tool to know where to find the definition being referenced. >>> >>> <extend_definition definition_ref="" >>> negate="" >>> comment="" /> >>> >>> The idea is that it might be easier to just point to that definition >>> instead of including it. Granted, we will still want to allow the >>> copying method if desired. I've given this some thought and would >>> like >>> to propose the following solutions for comment ... >>> >>> ============================================== >>> 1 - link an OVAL id namespace to repository >>> ============================================== >>> >>> The first option is to use the namespace portion of the oval id to >>> identify the repository where the content can be found. A master > list >>> would be kept and new repositories (that wanted to share content) >>> would >>> register their namespace with OVAL. We could then remove the > key_ref >>> and put the onus on the tool for find the definition by looking up > the >>> repository location via the id namespace. The unknown result could > be >>> used when an external definition can not be found. >>> >>> The biggest issue with this approach is that it puts the party in >>> charge of registering repositories "in the loop". When we worked on >>> the oval id format, one of the main desires was that we didn't want >>> organizations to have to rely on a 3rd party to produce content. >>> (what >>> happens when that 3rd party doesn't move fast enough, or at all?) >>> Hence the namespace portion of the ID. The proposal above would go >>> against this. Granted, registering a small (right now) number of >>> repositories would be easier and registering every id that is > produced >>> (this was our main concern). >>> >>> ============================================== >>> 2 - repository_ref attribute >>> ============================================== >>> >>> <extend_definition repository_ref="" >>> definition_ref="" >>> negate="" >>> comment="" /> >>> >>> The addition of the 'repository_ref' attribute would enable a > content >>> writer to state where to find the definition being extended. This >>> could be a URL to a repository, or maybe a file, etc. If just a top >>> level repository URL, a tool would then have to figure out how to > get >>> the actual xml fee from it. This idea would probably only work as a >>> URL to an xml doc. We will have to guard against URLs that >>> change/disappear. >>> >>> ============================================== >>> 3 - <external_definition> >>> ============================================== >>> >>> The third proposal is really just another point to think about and > is >>> something that could be combined with one of the other proposals. >>> Should we create a new element called <external_definition> to use > for >>> references to definitions not found in the current document. We > would >>> keep the <extened_definition> element the same and use it only for >>> definitions that are found locally. >>> >>> >>> I'm interested to hear everyone's thoughts on this matter. I guess > in >>> short, do you like the idea of a global repository map or do you > think >>> providing a URL would be more appropriate? >>> >>> The other pieces to this puzzle that will be addressed separately is >>> the need for guidelines related to external repositories so that > they >>> offer up the expected content and in a known way >>> >>> Thanks >>> Drew >>> >>> --------- >>> >>> Andrew Buttner >>> The MITRE Corporation >>> abuttner@... >>> 781-271-3515 >>> >>> 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@... > . 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@.... |
|||||||||||||||
bakerj
|
Paul,
As ids are defined now they are globally unique, but there is no defined connection between the namespace of an id and the location of the item being id'ed. How would you suggest making that connection in a way that a tool could predictably track down referenced definitions? I like the idea of a construct similar to the schemalocation attribute. I could see this working such that an interpreter would first look in the local document for the referenced item. Then if not found would attempt to look at the suggested location. I still think that the suggestion capability should allow for file paths, or urls. Regards, Jon ============================================ Jonathan O. Baker The MITRE Corporation Email: bakerj@... >-----Original Message----- >From: Dick Whitehurst [mailto:Dick_Whitehurst@...] >Sent: Tuesday, July 15, 2008 10:40 AM >To: oval-developer-list OVAL Developer List/Closed Public Discussion >Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an >external file/repository > >Drew, > >Since the ids are defined to be globally unique, I am opposed to >including information about their location into the language, except, >perhaps, as a hint, similar to the way schemaloc works for xml schema >validation. The OVAL processor should be allowed to use whatever >mechanism it chooses to locate the referenced definition(s). > >Dick Whitehurst > >-----Original Message----- >From: Buttner, Drew [mailto:abuttner@...] >Sent: Monday, July 14, 2008 8:18 AM >To: OVAL-DEVELOPER-LIST@... >Subject: [OVAL-DEVELOPER-LIST] Referencing definitions in an external >file/repository > >One of the topics discussed at OVAL Developer Days was developing a >for definitions to reference another definition (think about the ><extend_definition> element) without having to include copy of the >definition in the file. For example, a definition might want to >leverage an inventory definition that exists in the primary source >vendor's repository. In version 5, in order for the OVAL Definition >file to validate, that inventory definition would have to be copied >from that vendor's repository. Note that the schema has a key_ref that >enforces that any id given in the 'definition_ref' attribute is found >in the document. If this key_ref was just removed and it was not >required to include these extended definitions, there would be no way >for a tool to know where to find the definition being referenced. > ><extend_definition definition_ref="" > negate="" > comment="" /> > >The idea is that it might be easier to just point to that definition >instead of including it. Granted, we will still want to allow the >copying method if desired. I've given this some thought and would >to propose the following solutions for comment ... > >============================================== >1 - link an OVAL id namespace to repository >============================================== > >The first option is to use the namespace portion of the oval id to >identify the repository where the content can be found. A master list >would be kept and new repositories (that wanted to share content) would >register their namespace with OVAL. We could then remove the key_ref >and put the onus on the tool for find the definition by looking up the >repository location via the id namespace. The unknown result could be >used when an external definition can not be found. > >The biggest issue with this approach is that it puts the party in >charge of registering repositories "in the loop". When we worked on >the oval id format, one of the main desires was that we didn't want >organizations to have to rely on a 3rd party to produce content. (what >happens when that 3rd party doesn't move fast enough, or at all?) >Hence the namespace portion of the ID. The proposal above would go >against this. Granted, registering a small (right now) number of >repositories would be easier and registering every id that is produced >(this was our main concern). > >============================================== >2 - repository_ref attribute >============================================== > ><extend_definition repository_ref="" > definition_ref="" > negate="" > comment="" /> > >The addition of the 'repository_ref' attribute would enable a content >writer to state where to find the definition being extended. This >could be a URL to a repository, or maybe a file, etc. If just a top >level repository URL, a tool would then have to figure out how to get >the actual xml fee from it. This idea would probably only work as a >URL to an xml doc. We will have to guard against URLs that >change/disappear. > >============================================== >3 - <external_definition> >============================================== > >The third proposal is really just another point to think about and is >something that could be combined with one of the other proposals. >Should we create a new element called <external_definition> to use for >references to definitions not found in the current document. We would >keep the <extened_definition> element the same and use it only for >definitions that are found locally. > > >I'm interested to hear everyone's thoughts on this matter. I guess in >short, do you like the idea of a global repository map or do you think >providing a URL would be more appropriate? > >The other pieces to this puzzle that will be addressed separately is >the need for guidelines related to external repositories so that they >offer up the expected content and in a known way > >Thanks >Drew > >--------- > >Andrew Buttner >The MITRE Corporation >abuttner@... >781-271-3515 > >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@.... |
|||||||||||||||
|
bakerj
|
Thomas,
Looking at your example I think we would still be faced with greatly restructuring the current layout of an OVAL Definition's document to make this work. Currently we have five buckets in a valid oval definition document: 1- <definitions/> 2- <tests/> 3- <objects/> 4- <states/> 5- <variables/> A definition can directly or indirectly reference items in all 5 buckets. If we want to use something like xinclude we would need to be able to include a referenced definition AND all of the tests, objects, states, and variables that it references. Given the current structure of an oval definition document I think it may not be possible to leverage xinclude to include a definition and implicitly include all the items the definition references. Does this make sense? Is there a component to your suggestion that I did not follow? Regards, Jon ============================================ Jonathan O. Baker The MITRE Corporation Email: bakerj@... >-----Original Message----- >From: Thomas R. Jones [mailto:thomas.jones@...] >Sent: Tuesday, July 15, 2008 3:27 PM >To: oval-developer-list OVAL Developer List/Closed Public Discussion >Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an >external file/repository > >Ahhhh. I see the issue. It is still available through standardized >technologies through the following: > >My crude example > ><xi:include href="http://www.domain.com/remote_file.xml" >xpointer="element(oval_definitions/definitions/definition)"/> > >Or possibly if their are more than one definition contained within the >remote resource; all within the href attribute as: >"http://www.domain.com/remote_file.xml#xpointer(id(oval:org.mitre.oval >ef:number >" > >This explicitly declares that the entire element with that given id >located within the specified remote file is to be included in its >entirety to include attributes. > >Thusly, at any given point we may implement an entire document data >set.....or as you pointed out....specify data fragments at a given >position in which they are relevant. > >Thomas > >Sent from my iPhone > >On Jul 15, 2008, at 2:05 PM, "Buttner, Drew" <abuttner@...> > >> I am all for using accepted technologies like XInclude if we can, but >> one technical problem to overcome with this is that we can't just >> include an entire OVAL doc in one place. What needs to be included is >> a definition, plus any necessary tests (which need to go in the tests >> section), plus any objects (which need to go in the objects section), >> etc. I think we would have to change the way OVAL is structured to >> make this work. >> >> Rather than inclusion, I think what we really need is a way to say: >> instead of looking in this current OVAL doc, look over there for the >> information. >> >> Agree? >> >> Thanks >> Drew >> >> >> >>> -----Original Message----- >>> From: Thomas R. Jones [mailto:thomas.jones@...] >>> Sent: Tuesday, July 15, 2008 1:59 PM >>> To: oval-developer-list OVAL Developer List/Closed Public >>> Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an >>> external file/repository >>> >>> Why are we not leveraging preexisting, community accepted and >>> developed technologies, such as XML Inclusions(XInclude)? >>> >>> It will provide all the neccessary requirements for oval to remotely >>> query and parse data sets. Its implements URL escaping, so that we >>> don't have to. It already has a failure mechanism, xi:fallback, that >>> can be custom altered according to schema standard(and/or developer >>> preference). >>> >>> Automatically, disallows href link fragments. I.e. Everything after # >>> >>> And provides any and all resources available to the application that >>> is in accordance with the URL standard. Thusly, new and existing URL >>> schemes will automatically be accepted. >>> >>> Validating parsers are compatible and should be able to validate the >>> entire document set(to include remote data) as one entity. >>> >>> No new namespace declaration needed. No global repository needed. >>> >>> Comments? >>> >>> Sent from my iPhone >>> >>> On Jul 14, 2008, at 8:18 AM, "Buttner, Drew" <abuttner@...> >> wrote: >>> >>>> One of the topics discussed at OVAL Developer Days was developing >>>> way >>>> for definitions to reference another definition (think about the >>>> <extend_definition> element) without having to include copy of the >>>> definition in the file. For example, a definition might want to >>>> leverage an inventory definition that exists in the primary source >>>> vendor's repository. In version 5, in order for the OVAL Definition >>>> file to validate, that inventory definition would have to be copied >>>> from that vendor's repository. Note that the schema has a key_ref >>>> that >>>> enforces that any id given in the 'definition_ref' attribute is >> found >>>> in the document. If this key_ref was just removed and it was not >>>> required to include these extended definitions, there would be no >> way >>>> for a tool to know where to find the definition being referenced. >>>> >>>> <extend_definition definition_ref="" >>>> negate="" >>>> comment="" /> >>>> >>>> The idea is that it might be easier to just point to that >>>> instead of including it. Granted, we will still want to allow the >>>> copying method if desired. I've given this some thought and would >>>> like >>>> to propose the following solutions for comment ... >>>> >>>> ============================================== >>>> 1 - link an OVAL id namespace to repository >>>> ============================================== >>>> >>>> The first option is to use the namespace portion of the oval id to >>>> identify the repository where the content can be found. A master >> list >>>> would be kept and new repositories (that wanted to share content) >>>> would >>>> register their namespace with OVAL. We could then remove the >> key_ref >>>> and put the onus on the tool for find the definition by looking up >> the >>>> repository location via the id namespace. The unknown result >> be >>>> used when an external definition can not be found. >>>> >>>> The biggest issue with this approach is that it puts the party in >>>> charge of registering repositories "in the loop". When we worked on >>>> the oval id format, one of the main desires was that we didn't want >>>> organizations to have to rely on a 3rd party to produce content. >>>> (what >>>> happens when that 3rd party doesn't move fast enough, or at all?) >>>> Hence the namespace portion of the ID. The proposal above would go >>>> against this. Granted, registering a small (right now) number of >>>> repositories would be easier and registering every id that is >> produced >>>> (this was our main concern). >>>> >>>> ============================================== >>>> 2 - repository_ref attribute >>>> ============================================== >>>> >>>> <extend_definition repository_ref="" >>>> definition_ref="" >>>> negate="" >>>> comment="" /> >>>> >>>> The addition of the 'repository_ref' attribute would enable a >> content >>>> writer to state where to find the definition being extended. This >>>> could be a URL to a repository, or maybe a file, etc. If just a >>>> level repository URL, a tool would then have to figure out how to >> get >>>> the actual xml fee from it. This idea would probably only work as a >>>> URL to an xml doc. We will have to guard against URLs that >>>> change/disappear. >>>> >>>> ============================================== >>>> 3 - <external_definition> >>>> ============================================== >>>> >>>> The third proposal is really just another point to think about and >> is >>>> something that could be combined with one of the other proposals. >>>> Should we create a new element called <external_definition> to use >> for >>>> references to definitions not found in the current document. We >> would >>>> keep the <extened_definition> element the same and use it only for >>>> definitions that are found locally. >>>> >>>> >>>> I'm interested to hear everyone's thoughts on this matter. I >> in >>>> short, do you like the idea of a global repository map or do you >> think >>>> providing a URL would be more appropriate? >>>> >>>> The other pieces to this puzzle that will be addressed separately is >>>> the need for guidelines related to external repositories so that >> they >>>> offer up the expected content and in a known way >>>> >>>> Thanks >>>> Drew >>>> >>>> --------- >>>> >>>> Andrew Buttner >>>> The MITRE Corporation >>>> abuttner@... >>>> 781-271-3515 >>>> >>>> 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 >>> 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@.... 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@.... |
|||||||||||||||
Peng, Pai
|
I am also inclined to this option. It is probably more appropriate to name it as external_definition instead of extend_definition. I'd also like to have a optional md5_sum when repository_file is used, and some other mechanism to authenticate a repository_soa.
Thanks, Pai -----Original Message----- From: Ken Lassesen [mailto:ken.lassesen@...] Sent: Tuesday, July 15, 2008 9:20 AM To: OVAL-DEVELOPER-LIST@... Subject: Re: [OVAL-DEVELOPER-LIST] Referencing definitions in an external file/repository I am inclined towards: <extend_definition repository_file="" repository_href="" repository_soa="" definition_ref="" negate="" comment="" /> Where * repository_file="" -- indicates the file (typically co-located in the same folder), this handles the isolated machine scenario * repository_href -- indicates a web location to download from, http, ftp should be supported at least, * repository_soa="" indicates that a web services is available, i.e. string GetDefinitionXmlString(string definition_ref) which will return the explicit elements needed for this definition (MITRE repository can likely support this with little effort). BOTH of the following may be given (so we can support compression) repository_file="my-Oval-xml" repository_href="http://reddwarfdogs.com/oval.zip" Ken -----Original Message----- From: Buttner, Drew [mailto:abuttner@...] Sent: Monday, July 14, 2008 6:18 AM To: OVAL-DEVELOPER-LIST@... Subject: [OVAL-DEVELOPER-LIST] Referencing definitions in an external file/repository One of the topics discussed at OVAL Developer Days was developing a way for definitions to reference another definition (think about the <extend_definition> element) without having to include copy of the definition in the file. For example, a definition might want to leverage an inventory definition that exists in the primary source vendor's repository. In version 5, in order for the OVAL Definition file to validate, that inventory definition would have to be copied from that vendor's repository. Note that the schema has a key_ref that enforces that any id given in the 'definition_ref' attribute is found in the document. If this key_ref was just removed and it was not required to include these extended definitions, there would be no way for a tool to know where to find the definition being referenced. <extend_definition definition_ref="" negate="" comment="" /> The idea is that it might be easier to just point to that definition instead of including it. Granted, we will still want to allow the copying method if desired. I've given this some thought and would like to propose the following solutions for comment ... ============================================== 1 - link an OVAL id namespace to repository ============================================== The first option is to use the namespace portion of the oval id to identify the repository where the content can be found. A master list would be kept and new repositories (that wanted to share content) would register their namespace with OVAL. We could then remove the key_ref and put the onus on the tool for find the definition by looking up the repository location via the id namespace. The unknown result could be used when an external definition can not be found. The biggest issue with this approach is that it puts the party in charge of registering repositories "in the loop". When we worked on the oval id format, one of the main desires was that we didn't want organizations to have to rely on a 3rd party to produce content. (what happens when that 3rd party doesn't move fast enough, or at all?) Hence the namespace portion of the ID. The proposal above would go against this. Granted, registering a small (right now) number of repositories would be easier and registering every id that is produced (this was our main concern). | |||||||||||||||