OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: xml spec 1.0 validity constraint for ID/IDREF

[ Lists Home | Date Index | Thread Index ]
  • From: John Cowan <jcowan@reutershealth.com>
  • To: gopi <gopi@aztecsoft.com>, "xml-dev@xml.org" <xml-dev@xml.org>
  • Date: Wed, 29 Mar 2000 12:40:01 -0500

gopi wrote:

> I felt that XML is not just sub-set of SGML, but it puts some "restrictions"
> on SGML documents.

XML *is* a subset of SGML *because* it puts restrictions on SGML documents.

>  So, if you have any SGML document,
> and try to convert to XML document, it cannot be converted automatically or
> it is not well formed (or valid) XML document. So, it still differs with
> SGML in certain ways.  Even though SGML is the base for XML spec, it is even
> now not making sure that "every" SGML doc is not XML document (if you parse
> using XML processor).  (If what I have written is wrong, correct me before
> somebody also misinterpret).

No, this is correct.

>         So, why should we still stick on to this "buggy" definition for ID/IDREF.
> Anyway, SGML doc cannot be processed using XML processor.  If we change the
> definition of ID/IDREF , we are not doing any major change in
> "compatibility".

The compatibility issue is the other way about: SGML processors can accept
XML documents.  Changing the definition of an ID attribute would break that.

>         Here, I got it.  So what I said is correct. Every SGML document is not
> "well formed" XML document. So many of SGML features are invalid in XML.
> Let's do the same thing with ID/IDREF also?

On the contrary. You are trying to make an XML feature which is invalid SGML.

>         No, XML processor is not just doing this, it is doing that "extra thing" of
> checking the starting character of value.  Whether first character is letter
> or not :-(,  since it is specified in XML spec.

SGML makes a distinction between "name-start characters" and "name characters";
in addition, there are also other characters that are not allowed in names
at all.

XML inherits this distinction.

>         Instead of having one more layer of implementation, better to change the
> definition in XML spec itself.  I am sure w3c has really responded to
> XML-DEV activities positively.  They won't be so rigid to make us do one
> more layer of specification or implementation on XML spec.

Changing the XML spec is not impossible, but not easy either.  One of its
strong points has been its stability in a changing Web world.
 
>         But XML "has" to become that magic bullet since it has all qualities to
> become, but need some refinement.  It has already made so much news in the
> industry that, everyone is trying to solve their problem with XML and it is
> not possible to stop them now.  XML has to come up to their expectation in
> order to stand.

Just because a feature sounds appealing to you is not evidence that it should be
used in your application.

-- 

Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS