On 09/18/2015 12:48 AM, Leif Halvard Silli (russisk.no) wrote:
On 17 Sep 2015, at 2:20, Hussein Shafie wrote:
In a nutshell, in XSD 1.1, first allow any attribute in the content model
of all elements and then assert that the only allowed attribute names
are prefixed by "data-". Not very elegant and anyway would not help
XMLmind XML Editor which is grammar-driven.
Thanks for challenging me to learn XSD. ;-) Schematron next!
Assuming that "grammar-driven" means that there is a link between what
XMLmind XML Editor considers valid and what XXE allows authors to add
(via its graphical user interface), then (sic!), it makes sense that XXE
does not permit authors to add something that isn’t explicityly allowed.
But does the link between validation and authoring need to be one to one
in both directions? What about the possibility of allowin more (than
what the graphical user interface permits to add) to occur in the source?
Limiting ourselves to XSD 1.0 only, then, by permitting any attribute
and setting processContents to "lax", the validator will check the
predefined attributes for validity - but as well allow undefined
attributes. For instance, using Pixware/Olivier Ishacian’s XSD [1], one
may edit the <xs:attributeGroup name="globalAttributeGroup"> sections as
follows:
<xs:attributeGroup name="globalAttributeGroup">
<xs:attributeGroup ref="coreAttributeGroup"/>
<xs:attributeGroup ref="commonEventsGroup"/>
<xs:attributeGroup ref="xmlAttributeGroup"/>
<xs:attributeGroup
ref="the-data-attributes-and-many-others-of-course" />
</xs:attributeGroup>
<xs:attributeGroup
name="the-data-attributes-and-many-others-of-course">
<xs:anyAttribute processContents="lax" />
</xs:attributeGroup>
I have checked that the above works in Xmplipfy (a hand coding only XML
editor for OSX). By "works" I mean that Xmplify, with the above code in
place, will issue an error message whenever I use incorrect content in
the predefined attributes but it will as well allow any undefined
attributes without checking.
For instance it barks if I do this: <hr hidden="hid" data-foo="bar" />
But it is silent if I do this: <hr hidden="hidden" data-foo="bar" />
Could this also work in XMLmind XML Editor?
Don't know. I need to test this to give you answer. However, the
solution you suggest, foreign wildcard attributes intersecting the
"normal attributes", is not adapted to the design of XMLmind XML Editor.
See below.
Conceptually, it seems to me that this should work quite well in WYSIWYG
editor, since the user interface of a WYSIWYG editor would only allows
attributes to be added for which there is a graphical user interface.
Of course, the above XSD would allow authors to add all kinds of
attributes in XXE’s source view mode. And so, if the above *does* work
in XMLmind XML Editor, then I don’t understand why adding XSD 1.1
assertions would not make it work even better (since then one could even
put limitations on what it would be permitted to add via the source
editor interface of XMLmind XML Editor).
[1]
http://grepcode.com/file/repo1.maven.org/maven2/com.googlecode.l10n-maven-plugin/l10n-maven-plugin/1.5/xhtml5.xsd?av=f
Sorry but the solution you suggest, foreign wildcard attributes
intersecting the "normal attributes", is not adapted to the design of
XMLmind XML Editor.
Note that everything you said about "what about the possibility of
allowing more" already works fine, but using foreign *namespaces*.
Had the (X)HTML5 designers chosen "data:" prefixed attributes instead of
"data-" attributes, there would be no problem at all as XSD and RELAX NG
can express this (assuming that in this hypothetical (X)HTML5, prefix
"data" is bound to a namespace different from
"http://www.w3.org/1999/xhtml";).
Yes, I know, "data-" attributes exist for historical reasons.
--
XMLmind XML Editor Support List
xmleditor-support@xmlmind.com
http://www.xmlmind.com/mailman/listinfo/xmleditor-support
