RE: Roadnode Rodeo

>Today, I'm going to try to convince a few thousand of you, that the web is 
>headed for 'nodeserving'.  This, again, is the act of pulling or pushing... 
>single or tree-hierarchies-of xml/html elements around from place to place. 
>  Ted Nelson calls it 'transclusion' [2].  I call it COMING SOON.
>

Actually I think this needs to happen now.  I've got about a thousand uses 
for this technology and what it means.  Nodeserving as you say has a lot of 
other benefits as well.  For me the concept of reusable components for an 
author is core to this discussion.  I'd also like at a minimum to see a W3C 
note on the uses of XInclude with XHTML.  I think that if we thought of each 
structural element as a top level element (table, list, section, 
presentation, etc.) and allowed any of these to be a top level element with 
attached meta and styling information.  Essentially any of these could have 
their own styling section, but if they don't have one, they inherit from 
their parent's styling section.

If the top level structural elements where legal by themselves, I could now 
makes nodes of lists, tables, text blocks, etc that editors would actually 
handle.  The biggest problem with HTML is that it has a head element.  This 
element brings information about the body element outside the body element.  
And it's almost always redundant information.  It even says so in the <a 
href="http://www.w3.org/TR/xhtml2/mod-structure.html#s_structuremodule_issue_2">XHTML 
2.0 draft</a>.

Take a look at the structure elements.  The HTML element is also a structure 
element that only allows for one structure.  It's identical to section in 
many ways.  So why not use section?  Bring the meta and styling information 
inside and now we've simplified the standard, made it more extensible, made 
nodeserving possible, made componitization possible and made authoring tools 
simpler to write.  These are all good things.  Simplicity of concept here is 
going to make life easier.

>The TITLE attribute is meta data... and so is CLASS and ID.  In fact, class 
>and id should both be JUST id.  Make it so that if id is to be a class, its 
>used as @id="blah" or something akin to that.  Now, that leaves us with... 
>nothing.  No core attributes on the EM element... except... meta and style 
>(which need to be added).  Even the uncompressable up-to-122-css-property 
>style STRING that gets put into the style attribute for my sent MOOzilla 
>object (and other) tags... COULD be a member of meta's key/value set.  It 
>could be right there alongside class, id, title, author, node-sent-from, 
>date-sent, etc etc.  Would this be so bad?  A giant 'about' collection of 
>dublincore-like stuff, all possibly crammed into the lone meta attribute of 
>ANY tag/element?  In my opinion, if you don't want tag soup, you will need 
>attribute soup.  And how does one keep attribute soup under control?  By 
>putting all possible attributes plus some... into the single meta 
>attribute.  At least that's one way of looking at it. :)
>

Except soup is what you want from a usability perspective.  There are always 
going to be X structures you're going to have.  Whether or not you make an 
element or an attribute for them doesn't dismiss their existence.  Usually 
it just means people are going to find another way to use the existing 
structures to map to the new structures in their head.  There is a happy 
medium.  Making the most often used structures and given them their own tags 
and attributes and then leaving an extension mechanism in place is a good 
middle ground.

On a side note, there is currently no standard in regards to making 
something an attribute versus something an element.  I have yet to find an 
Note on it or any remarks in any specs, especially the XML spec where I 
would think to find it or a link to it.  The problem with making the meta or 
style an attribute is the sheer amount of data that will be included in 
them.  Also it makes authoring tools cry in the sense that they can no 
longer use their existing parsers to give us the niceties as authors we 
demand.  Also have a style attribute and a style element is a bit redundant. 
  Also the contents of the style attribute and also the meta element tend to 
be so long that it makes working with them in attributes hard to do.  Also 
style and meta could have complex contents.  Including XML tags in 
attributes means that every one has to be escaped.  We've attributed style 
with CSS, but it's not the same thing.  If an XML styling system came along, 
the style attribute just wouldn't work.  Same thing with meta - the contents 
of the meta needs to be taken out of the contents attribute and be put in 
the actual content of the meta element itself.

>Now, back to this peeking (retrieving) of 'computed style' FOR an arbitrary 
>transcludable element in an arbitrary open-for-transclusion document.  
>Folks, it doesn't look like any content management system or webserver will 
>be able to gather the value of all 122 css property values that WOULD be 
>applied to a certain document element if that document were rendered in a 
>browser.  This is one of the weaknesses of css, in my opinion.  Or maybe, 
>the 'feature' of 'cascading' caused this problem.

This does cause problems, but I think most of this is caused by an inability 
to componetize styling information.  This is different than applying styling 
information to each element than needs to be styled.  I am actually against 
a style attribute, but I do recognize the desire to place styling 
information closer to where the information actually applies.  I feel that 
central styling has falled miserably.  We've decoupled structure from 
styling which is a good thing, but we've also seperated the structure from 
the styling for an element.  I can't easily reuse components here because I 
need to include them in too places.  I need to include the actual structure 
in the document and include the data in an include in CSS.  This means that 
when I want to do a simple inclusion of information I now have to write two 
languages to do so.  And CSS isn't that easy to manipulate.

_________________________________________________________________
Get a FREE online computer virus scan from McAfee when you click here. 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Received on Saturday, 28 February 2004 11:04:31 UTC