[
Lists Home |
Date Index |
Thread Index
]
On Tuesday 18 February 2003 05:35 pm, Bullard, Claude L (Len) wrote:
> Ok, that is a deeper issue. I am assuming
> the expert designed the schema for the
> customer, not that he gave them one from
> a standard set. It depends on the tool
> as to how useful that is as an editing
> hint.
>
> Or did I misunderstand your point?
Just from an information modeling perspective, my point was simply that
namespaces really don't buy you much at all. As I've said in the past, I've
never really needed namespaces, though the prefix convention is at times
convenient. For text manipulation, they're just a little sugar and not much
more.
Now the real justification seems to be in "embedding" and having tools
intelligently handle content based on the namespace. Assuming an editing
application, the goal is (apparently) for the application, when it sees
<nikon:lens/>
to somehow, automagically, connect that to a particular schema that is then
used to control how I can edit the document.
First of all, the mechanism for automagically doing things like this has not
yet been standardized. We have URI's associated with namespaces, but we're
all aware of the huge debates surrounding "what is at the end of the rainbow"
there.
Second, even if we said that, at the end of a namespace URI, there is *always*
the appropriate schema (or RelaxNG, or schematron). I may, or may not *want*
the system to automagically do things like this. After all, I might be a
"power user", or I might want to bind to a particular *version* of the
schema.
All this implies (to me anyway) that there should be some control over the
mapping passed on to users. Now if the mapping is based on namespace URI's,
why couldn't it be based on an XPath or something suchlike? Then I could say
nikon:* || //*[manufacturer="Nikon"] http://www.foo.com/camera.rng
This obviously also touches on packaging... and is really an old idea in many
ways. Essentially, this is about providing *mechanisms* to build data-driven
applications.
|
