{"id":1233,"date":"2015-06-06T14:32:09","date_gmt":"2015-06-06T19:32:09","guid":{"rendered":"http:\/\/huewhite.com\/umb\/?p=1233"},"modified":"2015-06-06T14:32:09","modified_gmt":"2015-06-06T19:32:09","slug":"current-project-ctd-5","status":"publish","type":"post","link":"https:\/\/huewhite.com\/umb\/2015\/06\/06\/current-project-ctd-5\/","title":{"rendered":"Current Project, Ctd"},"content":{"rendered":"

Continuing my faintly ridiculous hobby<\/a>, I thought I’d add a note on XML validity constraints and how they interact with the EBNF of XML: which is to say, they don’t.<\/p>\n

Which is reasonable, of course: the point of the EBNF is to specify the syntax, not the semantics.\u00a0 But this does make validity checking a little more difficult.\u00a0 Here’s the first example of a constraint<\/a>:<\/p>\n

Validity constraint: Root Element Type<\/b><\/p>\n

The Name<\/a> in the document type declaration MUST<\/em> match the element type of the root element<\/a>.<\/p><\/blockquote>\n

And an illustration:<\/p>\n

\n
<?xml version=\"1.0\"?>\r\n<!DOCTYPE greeting SYSTEM \"hello.dtd\">\r\n<greeting>Hello, world!<\/greeting> \r\n<\/pre>\n<\/blockquote>\n
Note the word “greeting” in the !DOCTYPE and in the XML element.\u00a0\u00a0 So what does Production 1 look like?<\/p>\n
document ::= prolog element Misc*<\/p><\/blockquote>\n
element is the important piece here:<\/p>\n
element ::= EmptyElemTag | STag content ETag<\/p><\/blockquote>\n
Both EmptyElemTag and STag reference Production 5:<\/p>\n
Name ::= NameStartChar (NameChar)*<\/p><\/blockquote>\n
And it’s this Name which we’ll match against the DTD’s name.\u00a0 But, of course, Name is used in many other places, which I’ll omit listing here, so clearly we cannot modify the processing at Name to validate against the DTD; or, more accurately, a hacker might find some way to get there, but that’s not really good enough.<\/p>\n
More importantly, the element Production is also referenced from another location, namely Production 43, and again it would be inappropriate to modify the element Production to validate a special case.\u00a0 So, how to handle this, and potentially other special cases, and properly highlight the purpose of the modification to the EBNF?<\/p>\n
I hit upon using the previously described debug mechanism<\/a>.\u00a0 First, I defined the notion of a Production Post Processor:<\/p>\n
Post_Production_Processor = Handlers -> List(XML_OnePass) -> Dtd -> Int -> Int -> (Handlers, Dtd);<\/p>\n
In English, a production post processor accepts all the SAX handlers provided by the user, the current state of processing, the DTD, and (for convenience) the current line and column numbers; it returns potentially new versions of the handlers and the DTD.\u00a0 (Yes, I’m wondering if returning a new DTD is pointless.)<\/p>\n
I added an integer (name of Production) map to Post_Production_Processor map to the internal state of the SAX parser.\u00a0 This is updated by a new function, validity_constraint<\/em>, which functions as a parser, accepting a production Name and Post_Production_Processor and modifying the previously mentioned map with the information before executing the success<\/em> function.<\/p>\n
As you might have guessed, then, I’ve modified the p_out<\/em> function for a match between its name<\/em> argument and anything in the map from name to Post_Production_Processor.\u00a0 If one is found, the entry is deleted, and the post processor is executed.\u00a0 The success<\/em> function is then invoked, but using the results of the post processor rather than those passed in.<\/p>\n
Usage?<\/p>\n
vc = validity_constraint;\u00a0\u00a0\u00a0 # purely for readability<\/p>\n
…<\/p>\n
xml_doc = p_in 1 & start_doc & prolog & vc 5 validate_dtd_name & element & <misc> & one_p & p_out 1;<\/p><\/blockquote>\n
validate_dtd_name<\/em> is invoked when Production 5 terminates, and I’ve determined that the next Production 5 will ALWAYS be the outermost element’s name.<\/p>\n
For comparison, here’s the original EBNF of Production 1:<\/p>\n
document ::= prolog element Misc*<\/p><\/blockquote>\n
The added implementation elements are p_in, start_doc, vc, one_p, and p_out.\u00a0 The transformation is rather large, but still straightforward:<\/p>\n
p_in<\/em> is the debug (and now validity constraint) mechanism;<\/p>\n
start_doc<\/em> implements the content handler’s start_document<\/em><\/a> functionality;<\/p>\n
vc<\/em>, as discussed;<\/p>\n
one_p,<\/em> the processor specific to Production 1 – not all Productions have processors, but this one does (it returns the handlers to the caller);<\/p>\n
p_out<\/em>, as discussed.<\/p>\n
Most productions only have p_in<\/em> and p_out<\/em> additions.\u00a0 A few have processors.\u00a0 So far, only Production 1 has a post processor, for which I should probably come up with a better name: validity processor, perhaps.\u00a0 Let me know if you have a better name.<\/p>\n
I should change xml_doc<\/em> to document<\/em>, just for consistency.\u00a0 (Consistency is rarely of interest to me, sadly.)<\/p>\n
Testing of this mechanism has yielded positive results, in that I can see the processor invoked.\u00a0 I have to modify one of my tests to have a DTD in order to really test it, and I haven’t gotten that far; if a DTD is not defined, the requirement is ignored.<\/p>\n
I look forward to trying to implement other validity constraints with this mechanism.<\/p>\n","protected":false},"excerpt":{"rendered":"
Continuing my faintly ridiculous hobby, I thought I’d add a note on XML validity constraints and how they interact with the EBNF of XML: which is to say, they don’t. Which is reasonable, of course: the point of the EBNF is to specify the syntax, not the semantics.\u00a0 But this \u2026  Continue reading → <\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"nf_dc_page":"","_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1233","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/posts\/1233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/comments?post=1233"}],"version-history":[{"count":3,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/posts\/1233\/revisions"}],"predecessor-version":[{"id":1236,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/posts\/1233\/revisions\/1236"}],"wp:attachment":[{"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/media?parent=1233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/categories?post=1233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/huewhite.com\/umb\/wp-json\/wp\/v2\/tags?post=1233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}