Brain Age

Brain Age is a total rip off of an idea I’ve had for years but just didn’t execute on. Sure the reasons are all there – no time, marketing channel, blah, de blah, de blah.

 

Fact is, I, like most of all ya all, am much more prolific a producer of ideas and less of product. Product requires execution and, more importantly, commitment. Comittment requires discarding other ideas which are relentlessly generated by my non-linear mind through the faculty of my often caffinated brain (is there a difference? Yes, but before you enage me in dialog, please get some background).

 

This is a naturally disturbing thought for the idea-creator. No more ideas while the commitment plays out. How to resolve this? One thought is that it is a discipline of sacrifice (trading the plentiful for the rarified). Another is that this is the reason teams and organisms exist: specialization. A further is that the world is wack, schrewed up, and needs to just take a flying leap since all I want is to generate ideas and get paid for it, yet the opportunities to be a research shmuck while lacking any kind of degree are, within my experience, non-existant.

 

Well, that’s enough thinking for now. Back to execution – it’s what I get paid for.

 

 

Filed under: Metathought

xsd:any and the Unique Particle Attribution constraint

Here’s a beauty –

 

"Wildcard ‘##any’ allows element ‘foo’, and causes the content model to become ambiguous. A content model must be formed such that during validation of an element information item sequence, the particle contained directly, indirectly or implicitly therein with which to attempt to validate each item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence."

 

Whew, ok then. So that’s one thing you can do if you are an out of work English Lit major – write prosaic exceptions for Microsoft.

 

You’ll find that when you have an xsd:any element (a "wildcard") in your XSD schema and try to run an XML document through validation using that schema in .Net 2.0. This is because you are violating the Unique Particle Attribution constraint on schema models. (What is a particle? The short, and usually sufficient answer is that it is the ‘abstract base class’ for elements and groups [and wildcards]. The long answer is here.) The Unique Particle Attribution constraint (UPA) states that any given element in an XML document has to be able to be assigned to one and only one declaration in the associated schema. Wildcards can mess with this in much the same way that they mess with your carefully constructed Regular Expressions – they eat too much. Consider the following declaration from a schema:

 

<xsd:sequence> 
    <xsd:element name="foo" type="xsd:string" minoccurs="0" maxoccurs="unbounded"/>  
    <xsd:element name="bar" type="xsd:string" minoccurs="0" maxoccurs="unbounded"/>
    <xsd:any minoccurs="0" maxoccurs="unbounded" processContents="skip"/> 
</xsd:sequence> 

Now if I had the following XML document, all would be well:

<foo>MyFoo</foo>
<bar>MyBar</bar>
<baz>MyBaz</baz>

…but the following would cause problems

<foo>MyFoo</foo>
<bar>MyBar</bar>
<bar>MyBar</bar>

You can see why. Which schema definition do I attribute the second <bar> element to? It could be the element definition or the wildcard. This is what makes the XML validator fall down, or at least should make it, since it violates the standard’s UPA constraint. It seems, however, that the validator in .Net 1.1 didn’t fall down here… I just downloaded the User Interface Process Application Block and compiled and ran the Insurance Client Managment quickstart and it fell down on the provided XML and XSD (the xsd has a wildcard). I’ll have to wait to try it on 1.1 since I don’t have it installed at work here, but my expectation is that it will work – incorrectly work, that is.

 

So, that leaves the question: is xsd:any a useful thing or not, if it breaks content models so easily? There are two camps. The next post on this subject will explore these camps.

Filed under: Getting Data

Paths in Asp.Net 2

It’s not immediately evident how to find where you are currently, in terms of the web site and server, in an Asp.Net app. MSDN comes to the rescue here, mostly, with a decoder ring page, but it’s not easy to find itself.

 

It is here, however.

 

Basically, the points are:

 

• Use the tilde character – "~" – in server controls and code, since it parses this out to mean "this application’s root URL". Don’t try to use this in JS or other client-side stuff, though.
• HttpRequest.ApplicationPath provides this same info, but is less declarative and more clutter
• HttpRequest.CurrentExecutionFilePath gives you the app root, any folders and the executing page. This is true even after a Server.Transfer or a Server.Execute.
• HttpRequest.FilePath is similar, but gives the original (calling) page after Server.Transfer or a Server.Execute.
• HttpRequest.Path returns the current URL path, exluding the host (and related kit). This also includes any "trailers" after the page, like …/default.aspx/blah/blah/blah
• HttpRequest.PhysicalApplicationPath is the root path on the disk of the server where the application lives – corresponding to ApplicationPath. Don’t send this to the client.
• HttpRequest.PhysicalPath is the physical path of the currently executing page.

 

Filed under: .Net Basics