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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Order of attributes

[ Lists Home | Date Index | Thread Index ]

In article <abd24ff9f23d1848108f9d0a94cb3a6f@rbii.com> you write:

>I'm probably being thick.. but I don't understand this. That's probably 
>because I think *semantics* are entirely in the eye of the beholder.

If they were *entirely* in the eye of the beholder, then XML wouldn't
help interoperability at all.  For example, as I suggested before, you
could encode all your information in the spacing between attributes,
but then what good would it be to use XML?  No other XML tool would
understand it.

Long ago ASCII, and later Unicode, saved us from having how to decide
how to encode characters for each application.  Apart from saving us
the effort of choosing, this had an obvious advantage: we could write
all kinds of tool that were useful for many different file formats.
We could edit Fortran programs and invoices with the same editor.  We
could grep for strings or count lines in any kind of text file.

XML does the same at the next level up: it saves us from choosing
a format for simple nested structures and named attributes.  And
it lets us build generic tools that can do useful things with all
kinds of XML document - consider XSLT for example.

We have gained that at the expense of removing some semantics from the
eye of the beholder.  We accept start and end tags as meaning some
kind of nesting.  We accept attributes as things that are identified
by name, not position.  And we accept white space inside tags as just
being for formatting and readability.

A binary file could be considered to conform to the "grammar" of ISO
Latin-1, because it consists of a sequence of 8-bit bytes.  But it
isn't Latin-1, because the bytes aren't interpreted in the way that
Latin-1 specifies.  Likewise a file that looks like XML but assigns
significance to attribute order may conform to the grammar of XML, but
it isn't XML.

And this is a good thing, because imposing such (minimal) semantics
allows us to write a range of generic XML tools.

>It seems to be that *some* editors might understand *all* of the 
>semantics of XML (as I believe you mean it), but augment them with 
>constraints/semantics above and beyond those?

Yes, an XML editor could do that.  But when it preserved the order of
attributes, it would be operating merely on the syntax.

-- Richard




 

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

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