[XML-DEV Mailing List Archive Home]
[Reply To This Message]
Re: choosing sides
- From: BillClare3@aol.com
- To: firstname.lastname@example.org
- Date: Sun, 12 Dec 2010 11:23:05 EST
A note on compatibility (from one who is looking for more fundamental
First - backward compatibility needs to be absolute, in that all that is
out there needs to be useable.
Starting points for syntax:
* Already, XML prolog has options for the parser.
* Existing browsers parse existing XML and can be extended.
* Data for XML applications comes in a variety of formats, including XML
* XML users, with a variety of needs, range from programmers to
subject experts and "tweakers".
And as a basis for more exciting capabilities
* Existing browsers already allow some interaction between the use
interface and the specification - e.g., "View Source".
XML needs to allow for more than one reader / parser; some standard,
some user written - to extract data from complex documents. One
particular need is for error handling specifications for both detailed
status and end user alerts.
Note also that parsing specifications can be internal, or can be provided
externally, when the data source is to be processed.
Note also, that a basic diagram editor, with built in parsing for
generating / validating specifications, can serve as a basis for
integrating comprehensive tools in a way that does not limit the
capabilities of using any of XML in a consistent way including evolving
capabilities. (I'm assuming here somewhat that a new XML has basic
facilities for presentation of hierarchies and networks, as well as list and
Compatibility in semantics is a thornier issue, but needs to be addressed
similarly - such as through extended and alternative infosets.
In a message dated 12/12/2010 7:23:18 A.M. Eastern Standard Time,
Hearkening back to Elliotte's proposal about forming a group to
details off-list - did that already happen? If so, and its
more-or-less with the ideas that got generated over the last
two, I'd be interested in participating. If there's no cabal yet,
think it's time to form up (at least one) side, like Amy
Here's my summary of outstanding ideas, possibly filtered by my
selective memory, with my own perspective.
I think this list may have
some similarity to Pete's blend:
http://codalogic.com/xmllite/xmllite.html, but perhaps a bit more
concern for XML 1.0 compatibility? I guess this would be "Mike's
not my ideas, mostly, but my wish list.
For the moment I'll
call new xml SXML ("simpler" XML? "super" XML?) :
1) Define a stance on
XML 1.0 guarantee - every well-formed XML
1.0 document encoded in
UTF-8/16 is a well-formed SXML
document. I think that's do-able,
even with the proposed
However the converse wouldn't be true.
SXML is looser; it includes
support a statement like: every SXML document can be
represented by an
"equivalent" XML 1.0 document - the data model is
same. This wouldn't be a perfect round-trip guarantee:
lose prefix mappings, duck-typing and other new features; just
of translatability guarantee - details to be worked out to see
if there is
a meaningful guarantee that can be had :)
another stance that could work is: parsers can support all
of XML 1.0,
XMLNS 1.1, AND SXML - we'd have to design SXML so there
outright conflicts. But it could be a reasonable thing to
SXML parser that lacks support for some XML 1.0 features.
there's a "profile" defined in the document itself, as has been
2) New Features
- new (like
Kay-style hierarchic) namespaces - I'm sure there will
be all kinds of
interesting discussion about how this could work out :)
looser handling of prolog (allow whitespace)
DOCTYPE (internal DTD set is parsed and preserved (?) for
re-serialization purposes only) - does SAX have an event for
ignoreableWhitespace maybe? Not sure how
this would play out
- treat XML decl as a
PI, but also:
warn about incompatible character set?;
assume utf-8 and
error when invalid utf sequence
- duck-typing (provide additional event
w/typed values) - this seems
do-able to me for int, date, dateTime and
float. Possibly even ID for
anything else that's
- built-in entity set (ISO
- allow nested comments; no requirement for
(use existing syntax) - <xml:comment> is
- I think CDATA needs to stay for
compatibility, but maybe there's a
SXML-only mode that ignores
- multiple root elements or documents in a single
- UTF-8 and UTF-16 autodetected based on BOM (no BOM
- looser handling of ampersand - does it
really need to be an error
to have &foo &
- also: undefined entities could be allowed
and left unprocessed
- all whitespace preserved by
default (even CRLF, but parsers can be
configured to do
- end-tag minimization; using </>? possibly
only on leaves? <//> for
close-all-elements? I don't actually
like this last one much, but
someone did mention lisp's close-all bracket:
], and this syntax just
sprung into my head...
Note: I don't really
intend to start a whole new round of discussion on
this list, although
that may be inevitable, but I'm really hoping a few
folks want to work out
a small manifesto, figure out the implications
for users and tools and
documents, and build some proof-of-concept
software - I'm going to
go away and work on my SXML parser now
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.
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format
Stylus Studio has published XML-DEV in RSS and ATOM formats,
enabling users to easily subcribe to the list from their preferred news reader application.
Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website.
they were not included by the author in the initial post. To view the content without the Sponsor Links please