Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define whether parameters in abstract patterns are expanded in diagnostics and properties #19

Closed
dmj opened this issue Aug 31, 2021 · 2 comments
Labels
abstract constructs Issues relating to abstract (patterns, rules) clarification Discusses and clarifies ambiguities element pattern Issues relating to element pattern

Comments

@dmj
Copy link
Member

dmj commented Aug 31, 2021

See #10

@rjelliffe
Copy link
Member

Yes, it is 100% a mistake if they do not.

In fact, sch:property makes little sense without them, as you want computed values with information from the document. In particular, this is for "feature-extraction" usages more than classic "validation", perhaps.

Sch:diagnostic elements really need it, because the intent is to provide specific information to the user, to allow location and understanding of the problem. In fact, an over-thinker might say that assertions used properly should not allow sch:name and sch:value-of because their only use is for diagnostic text (e.g. error messages), but an sch:assert's text is a positive statement about the business requirement.

@AndrewSales AndrewSales added element pattern Issues relating to element pattern abstract constructs Issues relating to abstract (patterns, rules) labels Jun 19, 2023
@AndrewSales
Copy link
Collaborator

Closing in light of #10 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
abstract constructs Issues relating to abstract (patterns, rules) clarification Discusses and clarifies ambiguities element pattern Issues relating to element pattern
Projects
None yet
Development

No branches or pull requests

3 participants