NOTE: The current preferred location for bug reports is the GitHub issue tracker.
Bug 480 - move legacy.rnc to syntax/relaxng dir during build
move legacy.rnc to syntax/relaxng dir during build
Status: RESOLVED FIXED
Product: Validator.nu
Classification: Unclassified
Component: HTML5 schema
HEAD
All All
: P2 enhancement
Assigned To: Michael[tm] Smith
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-15 04:27 CEST by Michael[tm] Smith
Modified: 2009-05-01 09:38 CEST (History)
1 user (show)

See Also:


Attachments
patch with proposed change (857 bytes, patch)
2009-04-29 13:52 CEST, Michael[tm] Smith
Details
diff showing complete changes to legacy.rnc since initial add (2.84 KB, text/plain)
2009-04-29 14:01 CEST, Michael[tm] Smith
Details
log showing all change descriptions for legacy.rnc since initial add (799 bytes, text/plain)
2009-04-29 14:03 CEST, Michael[tm] Smith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael[tm] Smith 2009-04-15 04:27:03 CEST
The current whattf/v.nu schema for HTML5 is non-conformant with the spec in that it includes some (obsoleted) elements that the spec does not define at all.

i recognize that that the schema by itself is already not completely conformant with the spec, in that the schema does not (and cannot) completely express all of the constraints that are defined in the spec. But  I think there is a signficant difference between the case of being incomplete in terms of conformance, and the case of having specific instances of non-conformance (such as this case of allowing elements that the spec doesn't define).

I also well recognize that the fact that those element are in the schema is a conscious design choice, as well as the fact that it's not an issue for v.nu because v.nu doesn't use the schema in isolation but instead uses it along with the additional assertions-processing step -- where those elements get explicitly reported as obsolete.

And I recognize the value of having v.nu explicitly catch and report those particular elements, and I'm not suggesting that behavior should change (if anything, I think v.nu should do such reporting for even more elements, and even obsoleted attributes, too.)

But I think that people -- regardless of what we try to do to limit availability of the schema and to admonish people to not use it alone for validation -- will eventually end up using the schema in "standalone" fashion, outside of v.nu, without using the assertions processing or any of the other non-schema checking that v.nu does. So there's some potential confusion/harm in having a non-conformant schema around at all.

I'm not sure what the original rationale was for having the elements in the schema to begin with, but if it was due to wanting to have the obsolete-element errors reported first -- instead of having it first report the (really unhelpful) jing default "Error: Element foo not allowed as child of element bar in this context" that it would otherwise report if the elements were not in the schema -- then I think one way to deal with that would be to switch the order of processing in v.nu such that the assertions checking is run prior to the schema checking.
Comment 1 Michael[tm] Smith 2009-04-16 15:38:09 CEST
So I changed the Summary description for this issue to better reflect what problem I meant for it to address. And a perhaps-better solution for that problem is to instead move the legacy.rnc to a different location in the source repository, then have the build move it back to its current/expected location at build time.

<MikeSmith> hsivonen: btw, since I've not yet met my quota of suggesting at least one idea a day to you that you probably won't like: What do you think about the idea of not keeping the legacy.rnc file under source control at all (or in separate source-control elsewhere), but having it instead pulled in or generated by the build?
<MikeSmith> hsivonen: I ask because I worry about people eventually re-packaging the whattf HTML5 schema with that file included
<MikeSmith> (the include statement for it would then also need to added as part of the build)
<hsivonen> MikeSmith: I'd rather autogenerate the 'driver' schemas that include the modules
<MikeSmith> hmm, yeah
<hsivonen> MikeSmith: I suppose legacy.rnc could be hidden in the validator svn repo or something
<MikeSmith> yeah
...
<MikeSmith> hsivonen: if you think it would be work considering, I can work on a patch for pulling in legacy.rnc and generating the drivers.
<hsivonen> MikeSmith: OK
Comment 2 Michael[tm] Smith 2009-04-29 13:52:14 CEST
Created attachment 89 [details]
patch with proposed change

Committing this patch will also require removing the legacy.rnc file from the syntax repository, and adding it as a new file to the validator repository under a new schema/legacy/ subdir.

There's no way I know of to preserve the revision history for a file in svn if you move it across repositories, so the history for legacy.rnc will be lost. But anyway, only three changes were ever committed to it: one was that the <font> element was added, the second was that , and the third was that the change that got rid of *.embedded stuff and changed it to just *.phrasing.

I guess I can attach the diff and log for it here, so we have a record at least.
Comment 3 Michael[tm] Smith 2009-04-29 14:01:17 CEST
Created attachment 90 [details]
diff showing complete changes to legacy.rnc since initial add
Comment 4 Michael[tm] Smith 2009-04-29 14:03:13 CEST
Created attachment 91 [details]
log showing all change descriptions for legacy.rnc since initial add