Re: [xml-dev] HTML5 and almost no namespaces

[Michael Sokolov <sokolov@ifactory.com>]

On 6/3/2011 9:09 AM, David Lee wrote:
> Agree 50% .  Certianly you can optimize a tagset for a particular processor.
>
> But does that mean you *should* ?
>
>
> Once you go down the route of optimizing your XML for a particular processor
> all sorts of tricks become useful.
> For example MarkLogic works best on lots of small documents instead of very
> large ones, so for optimization I split up my 500MB XML file into about a
> million small ones.    Other processors have other tricks needed to get them
> to work optimally.
>
> My personal opinion is that shouldn't dictate the source schema design.  But
> rather be a post-processing phase optimized for a particular processor.
> Micro-designing XML schema for optimization on one processor can eventually
> bite you... say when you change processors or they come out with new
> performance characteristics in V(n+1).
I agree 150%! (just trying to make up the difference here?) with your 
underlying point: practical considerations *should* not impact source 
schema design; they belong in a different domain.  A big part of my job 
is essentially applying those transformations that ready XML for 
indexing, search and retrieval.  But we are often asked by our customers 
what they can do to prepare their data further upstream so as to 
minimize the costs that we impose.

I think that the tag naming question (person/name vs. 
person/person-name) falls right on the fine line: it saves some effort 
downstream at the expense (maybe?) of some clarity, succinctness and/or 
purity in the upstream model.  I guess for me the decision (in the 
source data model) probably hinges on whether there is any value in 
having two distinct tag contexts share the same name.

To belabor the //person/name and //place/name example: under what 
circumstance is it useful for these two elements to share the same 
name?  Do they have the same content model? I think not - one has 
family-name, suffix, and so on.  However, if you have a complex address 
model, and then you have shipping and billing addresses, you clear don't 
want all the fields duplicated in distinct models (shipping-street, 
billing-street? yargh!)

Not sure there is a clear takeaway here except to say that premature 
optimization may be bad, but late optimization can come at a high cost, too.

-Mike