Re: Related resources (was Re: Namespace or document gloss?)

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> Edd Dumbill wrote,
> > OK, I'll try again on this.  It seems to me that the sort of
> > bundles we might want to be able to apply to documents in an
> > indirected fashion, we might also reasonably want to apply in a
> > hardwired manner too.
>
> Agreed ... if it sounded like I was arguing otherwise it was
> only because it looked as tho' hard-wiring was the _only_
> possibility being considered.

Is this so?  I personally pointed out that for most purposes in my
typical use, that PIs would do the trick.  I certainly didn't discourage
anyone from doing anything else.  I also read some people puzzled with
what you are expressing, and some people discussing the matter with you.
Par for the course on XML-DEV, I'd think

Again, for me personally, if it had to be something handled generically, I
would consider it a job for resolvers or RDF.  I don't think I need a
level of indirection built in, though.

Indirection is IMO itself just a hard-wired graph annotation.  I could
argue that you are trading one level of hard-wiring for another.  But I
won't because it's no big deal.

> > The problem I think I want solving is some kind of
> > reconciliation between the proliferation of things like:
> >
> > <?xml-stylesheet .. ?>
> > xsi:schemaLocation
> >
> > Seems to me that we're solving this problem along the way here.
>
> Again agreed. And coming from the indirection direction it
> would be nice to have the option of _not_ having to hard-wire
> a reference to a stylesheet into a document instance: I've
> always thought that sat very uneasily with the desire to
> separate presentation from content.

Any maxim can be taken too far.  I can't agree that just because it's
better to separate content from presentation in general, that it's bad to
even have meta-data in the document indicating a separate schema, style,
etc.  This goes a bit to far, I think.

There is nothing wrong with giving hints to the processor.  Processors can
easily be made to avoid them if need be.

> If we could use related
> resources to eliminate those references and simultaneously
> manage to avoid (where desirable) replacing them with a new hard-
> wired reference to those related resources that'd be a win.

At some point, you've got to hard-wire.  I think exactly where this point
is can become a big-endian vs. little-endian dispute.

> It also looks like we might well find that multiple resource
> collections apply to a (part of a) document: via it's
> namespaces, hard-wired into the doc instance, external etc. So
> maybe we need something that'd end up looking a teensy bit like
> the CSS cascade (or, in software terms, a chain of Decorators).

Just want to note that I think the decorator pattern is complete nonsense
in this problem space.  Most attempts to extend OO patterns to general data
structure are.  Of course I'm of the opinion that most design patterns are
merely crutches for bad programming language design anyway (more than half
of them the last time I did an informal tally of the GoF book).

The next thing you know document fragments will be called flyweights or
something.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python