Closed MarkDavidson closed 8 years ago
@MarkDavidson, I believe this is still correct, though I wasn't involved in the investigation that caused us to change that best practice to what it currently says. Do you have a particular evidence/reason that that XPath doesn't do what we want?
I ran this past a few other people and they said it looked correct as well.
I think maybe the confusion is that we say "a selector like node() | @*
" and some people just interpreted that as "the selector should be node() | @*
"
@johnwunder that's basically what some customers are seeing in their content. Soltra is working with the source determine the right course of action, which might be changing what the source generates.
I can't figure out an actionable change to request, so maybe we should just close this issue. I tried to wordsmith the text, but I couldn't come up with anything better.
What about something like:
XPath treats elements (which it refers to as nodes) separately from the attributes on those elements. To select both XML elements and attributes, use both an XPath selector for nodes (such as
node()
,//node()
, ordescendant-or-self::node()
) as well as an XPath selector for attributes (such as@*
,//@*
, ordescendant-or-self::node()/@*
). Join these with a|
to indicate the union of the node selector and the attribute selector. Example selectors for common STIX scenarios are shown below.
This would help discourage copying and pasting the invalid selector, while still explaining (more clearly?) the need for the two-part selector.
I like that change!
👍
http://stixproject.github.io/documentation/concepts/data-markings/#controlled-structure
If not, this should be updated.
Thank you. -Mark