Docs: state that IDS regex patterns match the whole value - #449
Open
BIMvoice wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Restrictions page links regex101.com as a learning resource. Regex101 does not implement the XML Schema Regex flavour that IDS uses, and one difference in particular does not produce an error, it silently returns the opposite answer.
The page's own example contradicts the tool it links
The existing table says
DT[0-9]rejects "DT123". That is correct, and it is correct because IDS patterns must match the whole value. Tested withxmlschema, the library IfcTester uses to evaluate IDS patterns:DT[0-9]DT123.{0,10}WALL-EXTERNAL.{0,10}DOOR-01-A2So a reader who checks the documentation's own example in the tool the documentation recommends is told the opposite of what the documentation says. For a length constraint like
.{0,10}the effect is worse, because the pattern appears to accept values that IDS will reject, and nothing signals that anything is wrong.What this PR changes
The page already notes that flavours differ and points to XML Regular Expressions as authoritative, which is good. This adds the one specific difference that fails silently:
^and$^and$are not part of XML Schema RegexIt also mentions two free online testers that implement XML Schema Regex directly, so the anchoring is handled automatically.
On the two tools, so maintainers can judge
They are third party and not affiliated with buildingSMART, and the text says so.
xspatternlibrary and documents that XSD patterns match the entire string by default. I have not independently audited its output.If linking third party tools is not appropriate here, the anchoring explanation stands on its own and I am happy to drop the tool paragraph entirely. That is the part that matters; the tools are a convenience.
Happy to reword any of this to fit the manual's voice.