Re: [xml-dev] The triples datamodel -- was Re: [xml-dev] Semantic Web permathread, iteration n+1

[bry@itnisk.com]

> 
> Imagine a document formatting system that just ignores unknown tagging,
> the way Elliott proposes. Now imagine that an author invents a new
> admonition tag for a particular market. (The U.S. and Japan have special
> requirements, so European manuals published in those countries would
> need some way to distinguish admonitions that must be processed
> differently than in other countries.) As a result, the market specific
> part of the document will either be omitted entirely (worst case) 

I don't get this, this has always seemed to me to be a strength not a weakness.
The market specific part of the document will either be omitted entirely in
markets to which it is not relevant right? I think what you're arguing here is
about interop, that is to say I have extended a standard with market relevant
information for my application, it works great in my application, if another
application that knows nothing about my applications extensions needs to deal
with the market relevant information then there can be a problem but I'm not
sure for whom the problem actually is, is it for the people using my
applications data? If it is data brought into my application from another source
and then extended I would say no, go get the damn data from the original source
not second hand. If it is data generated by my application then the question is,
if you're gonna rely on a particular application why do you not find out if it
extends things in any way. 

Anyway I could go on with all sorts of ways that I think the problems are
unclear, the thing is that this way of handling document extension has proven to
be particularly useful for xml applications. I see papers and tutorials
published all the time about it, one particular popular motif being 'extend x
with rdf'!!! The argument is being made that this method of extension is so
efficient in regards to other methods that it should be defaulted to. Your
argument against it doesn't seem clear enough to me to drop a powerful method. 

>or
> formatted the wrong way (best case), probably just like any other block
> of text. Either way, if an accident happens, the company that publishes
> the manual would be liable to pay damages.
>
see when you're talking about doing something like publishing a manual then I
think you're arguing about the organisation that has the data has extended the
data with market relevant information and then they're too incompetent to change
their publishing methods. If you can't change the handling of the data in your
own applications then don't extend the data, that's my theory. 

 
> With XML, all hell still breaks loose when the format is changed. XML is
> no different from other formats in this respect.
> 
well sometimes when I see all hell break loose when the format is changed I find
that is because the system was built without a clear idea of how format changes
should be approached in a particular xml dialect, sometimes this is because the
dialect itself has not clear idea how format changes should be approached. Most
often it is because the developers have no idea that there is such a thing as
different models for how to handle changes, one of which, the most common is the
one under discussion, that model presupposes that unknown markup is ignored but
subtrees of known markup are not ignored, that means that any extension to the
system has to take that model into consideration. I consider that as something
that should be blamed on the developer, I can see how we might argue that this
is something that developers should not be blamed for because it is just too
much to expect them to be able to take into consideration in their hectic
work-schedule but given that it is something that I have learned to take into
consideration and pay attention to when I build applications I don't feel like
giving anyone else a pass on it (especially as I consider it to be something
that makes application building easier with xml data).