- From: Peter Murray-Rust <Peter@ursus.demon.co.uk>
- Date: Wed, 21 May 1997 09:21:24 GMT
- To: w3c-sgml-wg@w3.org
In message <199705210757.AAA18091@boethius.eng.sun.com> bosak@atlantic-83.Eng.Sun.COM (Jon Bosak) writes: [...] > > The ERB meets Wednesday morning, and we will be prioritizing all of > the subjects raised over the last week. Based on the discussion in ^^^^^^^^^^ I assume this includes a prioritisation between XML-LINK issues and XML-LANG. > the WG, it's a safe prediction that several of the recent proposals > will be eliminated from further consideration. I am surprised by the relative lack of discussion on XML-LINK (given that there was a lot when the spec first came out). I would commend the ERB to take basic link issues as a priority because, like Eric and Tim, I believe we have a spec which is sufficiently unclear that it cannot be reliably implemented. May I urge simplicity and a spartan approach where possible, even though I personally would like (say) addressing into character data and the use of ALL. May I also suggest that since (IMO) '3. Linking Elements' requires revision/clarification that issues of '4. Link Behaviour' are held until (3) is clearer. At least three of Tim's 6 concerns were request for clarification, rather than modifications to the language. My comments are: Link-1. Link-2. White space will be such a problem here that the ERB should take a very spartan approach and choose the simplest solution. If that means that no CDATA in mixed content can be located, I shan't complain. Link-3. This requires urgent clarification. Much as I like (ALL,*), I suspect that until we have thought this through, returning sets of Elements will be problematic. We haven't even started to address how these would be managed in EXTENDED links, e.g. <EXTENDED> <LOCATOR HREF="ROOT,DESCENDANT(ALL,BEAR)"> <LOCATOR HREF="ROOT,DESCENDANT(ALL,DWARF)"> </EXTENDED> Therefore, very reluctantly, I suggest we remove the ability to return multiple ELEMENTs. We may still need the use of ALL higher in the hierarchy: in "DESCENDANT(ALL,BEAR)CHILD(1,BED,XML-TYPE,SOFT)" we require the 'ALL'. This should be guaranteed only to return the first Element satifying the Query. However we must have a way of notifying the application that the query has failed. Link-4 (The behaviour of XLG). Since *I* (and possibly others) are confused about what an XLG *is* and *means*, I think its behaviour has to be deferred until later. (It's very important, but I think it confuses at this stage). Link-5 Resource. I have already posted for clarification on this. It seems clear that a resource must be sufficiently well identified to be a clear unit in the processor. For this reason I would propose that all resources were single Elements. No multiple elements, no PCDATA, no spans which are not well-formed. The reason I'm not keen on spans is that no one has helped to describe what is meant by them and whilst it may seem simple enough to take part of an event stream and label it as a span, it causes problems when the document is represented as an ElementTree. Link-6 Addressing into character content. I suspect this will generate a lot of discussion (it's been the most discussed of the Link-* topics so far) and it will detract from the other issues. I can't see it being done before July 1. Link-7 (Eric/PM-R). What is the structure of an EXTENDED link? Can it have other than two LOCATORs? (see Link-4) So - I request as simple a LINK spec as possible. It can always be expanded later. It's not trivial to implement, and I think the behavioural issues are an order of magnitude more difficult. [For example, suppose I have a document (ext1) with a number of EXTENDED links referring to resources in doc1, and I then access ext2 with a different set of EXTENDED links also referring to doc1. Do I *replace* the links from ext1 with those from ext2? Does it depend on whether ext2 has been created with NEW (i.e. ext1 and ext2 are both 'visible')? Does REPLACE wipe out ext1's links? This is a scoping problem, nowhere mentioned in the spec]. IMO XML-LINK is a much more important and critical problem than SD1. At present it's impossible to think of writing tutorial/examples/textbook, etc. on XML-LINK. P. -- Peter Murray-Rust, domestic net connection Virtual School of Molecular Sciences http://www.vsms.nottingham.ac.uk/
Received on Wednesday, 21 May 1997 05:22:11 UTC