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

xsd:anyURI #23

Open
davidcarlisle opened this issue Sep 30, 2017 · 7 comments
Open

xsd:anyURI #23

davidcarlisle opened this issue Sep 30, 2017 · 7 comments

Comments

@davidcarlisle
Copy link
Member

davidcarlisle commented Sep 30, 2017

Historically the W3C have had great difficulty in defining what a URL/URI was. the XSD 1.0 definition had some ... features, and XSD 1.1 redefined it to have the same value space as xsd:string (with the intention that you can use it with natural strings documents and any uri-encoding is done as some back end process cf a browser address bar.)

most of our existing cds have

<CDURL> http://www.openmath.org/cd/arith1.ocd </CDURL>

and the schema says

CDURL = element CDURL { xsd:anyURI }

so this matches or not depending on the built in anyURI definition.

Of the ones I have to hand rnv and xmllint says it is valid and emacs nxml mode says it is not

I don't really want to change the schema to make space explicitly allowed (doing that while referencing anyURI is a bit convoluted I think) and the schema is anyway in the openmath spec, so I suggest I just do a global edit and remove the space from xsd:anyURI elements. (I never liked those spaces anyway:-)

@kohlhase
Copy link
Member

I fully support this idea. I always hated the spaces.

@kohlhase
Copy link
Member

apropos nxml-mode, you have probably seen that I added the schemata under lib/RelaxNG and added schema.xml files where needed.

davidcarlisle added a commit that referenced this issue Sep 30, 2017
@davidcarlisle
Copy link
Member Author

davidcarlisle commented Sep 30, 2017

sorry about that I'd got them locally in my checkout but not checked them in:-)

I think the reason I didn't check them in at the time was ...

We should formalise that the ones under the standard in the website repo are (like the cds) just copies from here, and I should get travis to copy them each time so we know we are in sync. which probably means copying back from the omstandard build some of the schema/dtd conversion logic.

Alternatively (perhaps better) we could consider the ones with the standard as authoritative and this travis could copy them from Openmath.github.io and check them in here if different..

or we could leave it as now and just sync by hand as needed....

@kohlhase
Copy link
Member

This sounds like the answer to the other issue: #24

But just to be clear:

  1. currently, the CDs are not copied over automatically by travis?
  2. that would mean we consider the versions on the web site as the official verions?

This is contrary to my assumptions (and I think what is documented) I always had the idea that

  1. The version on the master branch in the CDs repository is the official version and the CDs on the web site are just a convenience copy.
  2. If there is any serious development on the CDs, we would do that on a fork or a branch in the CDs repository.

I think we should become very clear about the mode and document that, so that things are transparent and I do not forget.

@davidcarlisle
Copy link
Member Author

davidcarlisle commented Sep 30, 2017

yes content dictionaries are copied over from CDs repo to Openmath.github.io rep and checked in.

So the ones in CDs are the sources to edit although arguably the ones on the openmath,org website are authoritative (as that's the URL given by <CDURL>) but the only ones that should be edited are in CDs.

however the standard document itself has master version in the OMSTD repo and currently the schema are built as part of the standard.

Currently the schema are synced between the two repo by hand.

It would be possible for travis to do this. (either the OMSTD travis or the one here)

Separately we could consider schema development to be part of CD development and so edit them here and push to the website rather than pull from OMSTD. I half suggested that above but on balance I think it is correct that the schema is tied closely to the standard.

@kohlhase
Copy link
Member

Ah, you were talking about the schemata, now it makes sense to me.
I agree that schema development should be part of the standard development and not of the CD development. I also think by-hand-sync for the schemata is better.

Let us document this in the READMEs of the various repositories. I will make a first draft and then you can interate?

@davidcarlisle
Copy link
Member Author

OK

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

2 participants