Comments (6)
I think that this is best handled by guidance in the documentation rather than schema enforcement, for reasons @bworrell mentions (patterning, regex, etc.)
from schemas.
Just wanted to note that we'll want to coordinate this with several STIX tickets, notably:
from schemas.
Agree that the timezone issue should be documentation on strongly suggested practice that it always be included in timestamps.
Precision will need to be an attribute of the timestamp.
from schemas.
I covered xs:date and xs:dateTime in #34. For uses of cyboxCommon:DateTimeObjectPropertyType
how about adding a precision
attribute as I suggest in #34 and just re-use the cyboxCommon:DateTimePrecisionEnum that will be created?
As for the other issues:
- Timezone is strongly suggested
- Format should match xs:dateTime, unless doing patterning. When doing patterning, assume the target format is xs:dateTime.
- Use of the
@precision
attribute is invalid for CybOX patterns (when@condition
is set to anything other than "Equals") This is the one I'm most wondering about...how would we match against a datetime using both @precision and a CybOX pattern? I say just prohibit or at least strongly discourage it.
from schemas.
I agree with @johnwunder: I think the precision
attribute should be used to add value to instance data, and should be avoided when defining patterns. As such, we should probably clarify that in documentation (suggested practices doc and/or annotations).
from schemas.
Why would @precision be invalid for patterns?
I could see there being valid use cases for it.
@precision basically specifies how much of the DateTime typed field is relevant.
For an instance, this means you could specify something like something occurring at any time on a particular date.
You may want to say something similar in a pattern. For example, any File with a Created_Time occurring on 11/19/13. Technically you could do this by specifying a range of 11/19/13 00:00:00 to 11/19/13 23:59:59 but that seems kind of silly if we now have a @precision attribute to specify how much of the DateTime is relevant.
Is there some issue that I am missing why we would want to discourage @precision in patterns?
sean
From: John Wunder <[email protected]mailto:[email protected]>
Reply-To: CybOXProject/schemas <[email protected]mailto:[email protected]>
Date: Tuesday, November 19, 2013 11:21 AM
To: CybOXProject/schemas <[email protected]mailto:[email protected]>
Cc: "Barnum, Sean D." <[email protected]mailto:[email protected]>
Subject: Re: [schemas] Timestamp guidance and/or enforcement (#11)
I covered xs:date and xs:dateTime in #34#34. For uses of cyboxCommon:DateTimeObjectPropertyType how about adding a precision attribute as I suggest in #34#34 and just re-use the cyboxCommon:DateTimePrecisionEnum that will be created?
As for the other issues:
- Timezone is strongly suggested
- Format should match xs:dateTime, unless doing patterning. When doing patterning, assume the target format is xs:dateTime.
- Use of the @precision attribute is invalid for CybOX patterns (when @condition is set to anything other than "Equals") This is the one I'm most wondering about...how would we match against a datetime using both @precisionhttps://github.com/precision and a CybOX pattern? I say just prohibit or at least strongly discourage it.
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/11#issuecomment-28798203.
from schemas.
Related Issues (20)
- WhoisObj:WhoisContactType is defined in a non-standard way
- No default Controlled Vocabulary for LinuxPackageObjectType.Architecture
- VolumeObj:VolumeOptionType is abstract, but never extended
- Use of xs:choice when only one element is specified
- Choice implemented in a non-standard way for NetworkFlowObj:NetflowV9DataRecordType
- Issues around Object Subclassing
- Inconsistency in Object Relationship Expression HOT 1
- IANAPortNumberRegistryType Data Type is used only in Network Flow, but defined in Network Packet
- Consider Deprecating Socket Address Object
- Consider Simplifying/Refactoring ExtractedFeaturesType
- Refactor/Deprecate Base DataTypes HOT 1
- Consider Refactoring/Clarifying User Session
- Consider Deprecating Pools
- WindowExecutableFileType/DOSHeaderType is specified incorrectly.
- Create Separate Patterning Syntax/Language
- Determine Patterning Language Operators HOT 2
- Determine Patterning Language Syntax HOT 1
- We need a way of recording web forum postings and credential dumps HOT 1
- Typo in DOS Header Schema
- No data XML representation for PDFIndirectObject of PDFFile HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from schemas.