RE: [xml-dev] XML spec and XSD

["Len Bullard" <cbullard@hiwaay.net>]

Do whatever floats your boat, fella, but the reason we had them was to make
complex production of complex documents easy to do and easy to configure by
people who generally did not program for a living.

Pretty much everything else talked about in this thread was tacked on after
that.  It isn't a matter of spec goodness but historical fact.

Be seeing you.

len

-----Original Message-----
From: Jim Tivy [mailto:jimt@bluestream.com] 
Sent: Sunday, November 15, 2009 6:31 PM
To: 'Len Bullard'; Tim.Bray@Sun.COM; 'Mukul Gandhi'
Cc: 'G. Ken Holman'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] XML spec and XSD

Len

I think schemaless processing of XML is **ONE** reason to get rid of the DTD
(element,attr decls) from the XML spec.  There are likely a set of other
reasons - another reason being a concern of being inclusive of all schema
languages with respect to XML validation - eg: factor out the notion of
validity from core XML spec.

I am not sure how to deal with your modelling of designers/programmers or
"Facts are" statements - makes my brains fall out - however I am not sure
you want those addressed.

However, I think it **valid** that you pointed out the importance of
validation.

Jim

-----Original Message-----
From: Len Bullard [mailto:cbullard@hiwaay.net] 
Sent: Sunday, November 15, 2009 3:49 PM
To: Tim.Bray@Sun.COM; 'Mukul Gandhi'
Cc: 'G. Ken Holman'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] XML spec and XSD

That's nuts and the opinion of a designer who writes code wonderfully but
very few technical documents of any real complexity.

A DTD in a production system with many writers attempting to remain within
the constraints of a common document design found DTDs to be quite useful.
Otherwise markup was crap layered into already complex content.   The
programmer viewpoint of markup is but one viewpoint and can't be used to
post facto justify well-formedness as the basis of XML goodness.  

Facts are that now the usefulness of XML itself is questioned in many
quarters but at the time when SGML was used as the basis of complex
documentation systems that emphasized the accuracy of technical writing over
database design or streaming the DTD was crucial.

len


From: Tim.Bray@Sun.COM [mailto:Tim.Bray@Sun.COM] 

The textual flaw isn't that it doesn't mention XSD or RNG, the textual flaw
is that it mentions *any* schema language.   A very high proportion of
real-world XML processing is entirely free of anything schema-related.  The
vast majority of the XML value proposition is delivered by schema-free
well-formed XML.  Even in those apps that use a schema in their
specification, the vast majority of run-time processing is schema-free.  One
of the costliest common mistakes of XML app/language designers is putting
too much importance on schemas.  The XML specification shouldn't be
encouraging that mistake.

My own vision of what XML.next ought to look like may be found at
http://www.textuality.com/xml/xmlSW.html



_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php




_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php