Re: SD1 - Short End Tags [fmt]

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