</> as end tag

[Peter Murray-Rust]

At 01:43 02/11/97 UT, Simon St.Laurent wrote:
>While looking over the release notes for the 31 October 97 version of the
Java 
>MSXML parser, I noticed that they've added a 'feature' that allows for
'Short 
>end tags,' using </>.  This won't be too difficult to implement, perhaps,
but 
>it seems like an odd break with XML's (so far) rather strict rules for start 
>and end tags, particularly 3.1 of the 7 August 97 Working Draft:
>
>>The end of every element may (for elements which are not empty, must) be 
>marked by an end-tag containing >a name that echoes the element's type as 
>given in the start-tag...
>>Well-Formedness Constraint - GI Match:
>>The Name in an element's end-tag must match that in the start-tag.
>
>Is this something new going on with the spec, or is it just Microsoft?  It 
>looks like they fixed a lot of the bugs, but this may introduce some new 
>problems.  (They also allow ampersands in PCDATA, as long as they're 'not 
>followed by a valid name character.)  It seems a little early for XML to
begin 
>fragmenting.

I would urge readers of this list to adhere to the specs absolutely.  [I
pass no comments on the motivation for msxml supporting </> or &.] XML can
ONLY be implemented if everyone adheres totally to the specs.  I believe
this list shares the view that both data and software can be modularised so
that different parts of the effort can be investigated by different people.
For example I intend to rely completely on parsers (e.g. Lark, NXP) to
provide the parsing part of JUMBO at present. In similar vein I am
developing JUMBO with the clear motivation that it tracks everything in the
spec and implements it as far as possible. [I hope to release a new JUMBO
in a few days - I want to see how it sits on top of Lark first.]

Even when everyone agrees to implement the spec it is not easy. Any spec
has ambiguities and special cases. There are also genuine differences of
opinion about procedure in areas where the spec makes no comment. For
example there is an uncertainty about when a document can be validated -
can the author or the document assert that validation should/not take place? 

It is going to be EXTREMELY important that documents circulating in the
devlopers' community adhere to the specs as closely as possible. We already
have challenges from capitalisation (we are case-sensitive now, but await a
final resolution on the exact case of some names and a possible policy more
generally.) I know that when a policy is announced I am going to have to
transform many of my current prototype documents - that's the price of
being a developer :-) But I do not intend to change any to deal with
software that *knowingly* does not conform to the spec, nor do I intend to
test my software on any documents that knowingly do not conform to the
spec. There is quite enough problem with ones (including mine:-) that do it
unknowingly :-)

	P.




>
>Source: http://www.microsoft.com/standards/xml/xmlchgs.htm.
>
>Simon St.Laurent
>
>
>
>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)
>
>
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)