Namespaces, Architectural Forms, and Sub-Documents

[Peter Murray-Rust]

At 10:39 19/02/98 +0900, MURATA Makoto wrote:
>
>In message "Re: Namespaces, Architectural Forms, and Sub-Documents", Peter
Murray-Rust 
>wrote...
>> I hope that the "disgusting" refers to the use of 'img' and 'src' and the
>> implied semantics rather than the mechanism :-).  I am an advocate of the
>> *mechanism* (e.g
>> http://www.vsms.nottingham.ac.uk/vsms/talks/chemwebvei/020.html) where I
>> use XML-LINK explicitly to combine chemistry, maths and text. This has the
>> advantage that it avoids namespace problems. It also allows me to process
>> foreign files if certain assumptions are made.
>
>I  think that your approach works.  Do you think that this is the way 

Thank you. I should perhaps make it clear that the diagram was slightly
hypothetical (i.e. not a screenshot from JUMBO. I did at one stage manage
to EMBED a  molecule in an event stream but it wasn't stable). At present
JUMBO will manually deal with linked resources and treat them as separate
trees. NEW and REPLACE are easily catered for; EMBED is a problem  since it
has little meaning in a tree and for text event stream I am still deciding
on the best way to arrange flow objects for non-conventional objects (e.g.
maths, molecules, name-value pairs, etc.) Also the 'hypertext' support that
Java gives is hardly exciting.



>to go?  I.e., no namespace mechanisms but links only?  Or, do you think 
>that it should be possible to convert the link-based representation to 
>the namespace-based representation and vice versa?

[There is a current SIG/WG discussion on namespaces which I cannot publicly
comment on. My private view is that I shall wait-and-see what comes out;
from my point of view it's not trivial.]

I suspect that namespaces and links will co-exist.  I am certainly gently
tooling up for each of them. My little experiment with JUMBO-PLAY shows
both approaches. (Although only a single namespace is involved, I have
prefixed the output of my play.SAXSplit with PLAY:) 

The advantage of a single monolithic document is it's easier to traverse
(e.g. searches). Its disadvantage (for JUMBO) is that it can overflow the
JVM. The namespaces are explicitly expanded (i.e. every element name has a
namespace prefix). I would find scoping quite difficult until the rules are
VERY clear. It is very difficult to build a prototype system if one is not
sure what one *should* be doing. (This is distinct from not knowing what
one is doing, which is permanent :-). Certainty in the goal makes
programming about half an order of magnitude easier. Thus, for example, I
don't know 100% whether we shall have prefixes on attributes.

Note that one advantage of links is that what is hung on the end need not
originally be an XML document. I frequently parse legacy documents into
trees on demand. Maybe this could be managed by notation and embedded
'binary', but I don't understand that yet :-)

>
>Cheers,

Cheers

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)