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

Specify or forbid whitespace normalisation #24

Open
kohlhase opened this issue Oct 2, 2017 · 4 comments
Open

Specify or forbid whitespace normalisation #24

kohlhase opened this issue Oct 2, 2017 · 4 comments
Assignees

Comments

@kohlhase
Copy link
Member

kohlhase commented Oct 2, 2017

see OpenMath/OM3#134

@kohlhase
Copy link
Member Author

kohlhase commented Oct 3, 2017

This was already raised by David on the CDs repository. I think we should clarify this in the standard and the normative RNCs (actually everywhere). Assigning David and James to come up with a pull request.

@davidcarlisle
Copy link
Member

davidcarlisle commented Oct 4, 2017

The original OM3 issue says:

It is common OpenMath CD authoring practise (none that I personally like, but it exists) to assume whitespace normalisation, e.g. <Name> foo </Name> is assumed equivalent to <Name>foo</Name>. However, in contrast to MathML this behaviour is not specified. It should, or otherwise all CDs using that syntax are invalid.

I think the initial comment is not correct actually. The existing examples with spaces are valid.

The standard in words says CDName contains the name and for syntactic requirements explicitly defers to the relax schema, that says

CDName = element CDName { xsd:NCName }

which implies that the content is tokenized including white space normalisation and the resulting token checked against the NCName production. so

<CDName> arith1 </CDName>

is valid and equivalent to

<CDName>arith1</CDName>

and

<CDName>a r ith1</CDName>

is invalid.

So no change is needed but personally I'd be quite happy to remove the spaces from the core CDs they may not be invalid but they are not a good example to follow.

The same implicit tokenisation applies to xsd:date and xsd:integer etc, so the only ones where the status of the space was/is ambiguous is CDBase and CDURL which use xsd:anyURI the definition of which depends on exactly which version of XSD that you use (and is self-contradictory in XSD version 1)

That said, just because a change isn't needed doesn't mean an explanatory note couldn't be added somewhere.

@kohlhase
Copy link
Member Author

kohlhase commented Oct 5, 2017

personally I'd be quite happy to remove the spaces from the core CDs they may not be invalid but they are not a good example to follow.

I think that is the least we should do. The spaces are indeed a very bad practice. Would you?

@kohlhase
Copy link
Member Author

kohlhase commented Oct 5, 2017

That said, just because a change isn't needed doesn't mean an explanatory note couldn't be added somewhere.

I think this would be helpful, and also say that the spaces around are "bad practice" (deprecated). Would you make a pull request of this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants