[topicmapmail] Web Services

[Jan Algermissen]

Murray Altheim wrote:
> 
> Jan Algermissen wrote:
> > Murray Altheim wrote:
> >[...]
> >>Do people have to be aware of the list of IDs, or does
> >>the system just fail when either an expected ID isn't there, or
> >>when an inserted ID fails because it's already in use (or there is
> >>an error because of that ID).
> >
> > IMHO using element IDs for other referencing purposes than for reconstructing
> > the serialized graph are a bad choice anyway (as are PSIs that contain fragment
> > identifiers) due to the limitations they introduce when used over HTTP....
> 
> Hmm. I'm confused about that last statement. If I publish a Topic
> Map as a source of PSIs, or an XHTML document that references an
> XTM document acting as that source, either way I have a single
> XTM document containing multiple <topic> elements, where each is
> potentially the Topic "behind" that the published PSI. I do this
> because the PSI is yes, just a string, but the Topic is perhaps
> firmly interwoven in a lattice of relations that might be important
> to my processor. So those fragment IDs are important to me. Being
> over HTTP or not doesn't seem to make a difference here. It's a
> reference on a local file system too.

The problem with fragment identifiers is, that they are not part of the
message when you invoke a HTTP method on them. The consequence is that
no intermediary will see them and thus cannot add-in information it
might have about that URI.

Another problem is that creating flat namespaces (a single 'document' with
lots of significant fragments) will allways cause the whole document to
be transfered just to access the fragment (as said, the server will never
see the fragment, the user agent strips it off).

A more practical example is that you cannot, for example, submit a fragemnt
identifier-URI to a search engine for indexeing.  foo#1 and foo#2 are
exactly the same thing to them.


> 
> >> There may be other XML issues, but
> >>I'm guessing some are fairly easy to deal with (such as requiring
> >>all incoming and outgoing content be in UTF-8).
> >
> > Why that? Isn't the encoding attribute/HTTP header part only a hint
> > for the processing application? What do you mean?
> 
> A "hint" is perhaps putting it a bit mildly, though I know that
> word isn't your invention. If I have two or three XTM documents
> that have different encodings, I'm going to have to convert them
> all to a single encoding in order to merge their contents,

Puh...good point. But don;t XML parser use a preferred encoding
internally anyway (expat does)....but I guess in Java you'll get
Strings with different encodings all over - yes?


 for
> example, a Microsoft encoding, a Shift-JIS encoding, UTF-8 and
> UTF-16 big-endian. I'd probably convert everything into the latter.
> Absent the UTF-16, I'd probably go with UTF-8. Point is, I don't
> think you can just ignore this, unless you don't care about the
> actual display and interpretation of content.

True....


Jan


> 
> Murray
> 
> ......................................................................
> Murray Altheim                    http://kmi.open.ac.uk/people/murray/
> Knowledge Media Institute
> The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .
> 
>   "[The Bush Administration] criticises the focus on good and bad
>    food, saying it has not yet been established what acceptable
>    levels [of sugar, salt, and fat] should be. [...] And in the
>    UK, the Food Standards Agency has warned that poor nutrition
>    and lack of exercise means young people today on average are
>    likely to live shorter lives than their parents - the first
>    such reduction in more than a century."
>    US questions global obesity plan, BBC News.
>    http://news.bbc.co.uk/1/hi/world/americas/3401715.stm
> 
>    The FDA Recommended Daily Allowances for sugar, salt and fat have
>    been part of the mandatory labeling laws in the US for decades.

-- 
Jan Algermissen                           http://www.topicmapping.com
Consultant & Programmer	                  http://www.gooseworks.org