search

Schematron / schematron

Schematron "skeleton" - XSLT implementation
MIT License
93 stars 45 forks source link

Remove SVN and CVS artifacts #31

Open tgraham-antenna opened 7 years ago

tgraham-antenna commented 7 years ago

This moves everything in trunk up one level and removes the trunk directory.

It also removes .svn, CVS, .hgignore, and .DS_Store files/directories left over from previous incarnations.

(It's also a bit too much of a change to just commit without warning.)

vincentml commented 7 years ago

Is there anything to prevent this pull request from being merged? This pull request has been open for some time. Keeping these anachronisms from SVN and CVS in the main branch might start to cause some problems.

phax commented 7 years ago

I think the problem is, that nobody is actively maintaining this repository. Last change: 6 month ago...

vincentml commented 7 years ago

@phax I saw @tgraham-antenna a few weeks ago at Balisage and we talked about Schematron. This repository is the "home" of the Schematron skeleton XSLTs and is maintained. However a big concern is to not break anything by making changes. A test suite is needed, as is being discussed in issue #49. If you are able to help, for example by contributing test cases, that would be most helpful.

phax commented 7 years ago

@vincentml I'm more the Java guy (see https://github.com/phax/ph-schematron) and not the XSLT/Schematron guy. But if there is anything I can help (like batch execution or the like), drop me a note :)

tgraham-antenna commented 7 years ago

The reason why its not merged is the number of PR against the existing HEAD.

Maybe it's my lack of Git foo, but it took contortions to update the branch recently, and, e.g., e2399d6 now shows up in the network diagram three times. I don't want the contortions to have to be repeated for every PR.

This PR is about to become obsolete anyway. I think that the non-'schematron' directories under 'trunk' will now go straight to each being a separate Git repository. (Unlike the new 'schematron-test' repository, they won't reappear as submodules of the 'schematron' repository.)

tofi86 commented 6 years ago

Alright, I can understand that you didn't want to break the existing PR's. But what if people send more PullRequests and we stick to the old SVN base forever? Does this make more sense?

IMHO we should decise on the repo structure as soon as possible to have a clean base repository.

tgraham-antenna commented 6 years ago

I should have just committed this at the time rather than wait for approval.

I think that the thing to do now is to break up the current project into multiple projects and then remove the SVN/CVS/Hg/Eiffel artifacts from each individually. The 'trunk/schematron/test' directory is now a submodule, and that's not reflected in this PR.

To Do:

tofi86 commented 6 years ago

That sounds like a good plan! Thanks Tony!

Let me know if I can help you somehow...

vincentml commented 6 years ago

This proposed restructuring should make it cleaner to import Schematron XSLTs into other projects. For example, a git submodule importing schematron-xslt2 or schematron-xslt1 would import only that Schematron XSLT implementation.

tgraham-antenna commented 6 years ago

Yes, it should be cleaner.

Ideally, the structure of the submodule files and the structure of the files that you unzip from a release would be identical (since the release would be a subset of the module's files). That way, it shouldn't matter if another projects starts with an unzipped release and then 'upgrades' to using a submodule or if the project's source uses a submodule and the project's releases expect an unzipped Schematron release at that position in the project's release's code.

tgraham-antenna commented 6 years ago

If you want to help, you can pick a project and, after the project is created, do the per-project cleanup and get the (new) project working again.

For projects that depend on the Schematron XSLT code, that's (at least) a two-step process. The existing versions of the new project's code in the 'schematron' project can't be removed until the new project is shown to work, and the contents of trunk/schematron/code can't be elevated to the base directory until all of the new projects are shown to work. That means that a new project that depends on the code in trunk/schematron has to be made to work with a 'schematron' submodule that has the current 'schematron' code structure and later has to be revised to work with the Schematron code elevated to the base directory.

Frankly, I don't know if 'ant-schematron', 'converters', or 'xsd2sch' currently work and/or can be built at all. There were/are assumptions about directory structure in the preexisting test directory that weren't reflected in the repository structure (but that's less of a problem with SVN, where you can check out parts of a repository in different places). I don't know what echoes of previous machines still exist in other directories.

tgraham-antenna commented 6 years ago

'ant-schematron' now exists as a separate project. The build.xml file for testing 'xsd2sch' uses ant-schematron.jar, hence the priority. 'xsd2sch' also has an XProc pipeline file, but I haven't tried that yet.

Schematron/ant-schematron#1 asks @rjelliffe if he has a build file for ant-schematron.jar, otherwise someone will have to make a new one.