[
Lists Home |
Date Index |
Thread Index
]
Alaric B Snell wrote:
> As I say, I'm no poet, so these are just a few stabs at it. But I don't
> see how XML can be any better at this than ASN.1 just because it is a
> textual syntax? If, as you say, the important properties of the poem
> cannot be extracted to 'metadata' usefully, then surely the poem in XML
> is best represented as the textual content of an element with whitesapce
> preserved, right? Which is just what ASN.1 strings provide, no?
>
> I have a creeping feeling I've perhaps missed your point ;-)
I just had another idea. Say you wrote an application that read XML
documents but depended on something *conventionally* ignored - perhaps
it processes the file significantly differently depending on the
encoding the file happened to be in when it read it, or something like
that - or perhaps an XHTML browser that behaved significantly
differently when an image had width="010" than when an image had width="10".
(I've said "significantly differently" to exclude cases like 'A generic
XML editor tries to save documents back in the same encoding it read
them in' or 'The XHTML browser shows leading zeroes on width attributes
when you hit View Source')
Would you not say that those applications are broken for being sensitive
to such 'irrelevant' syntactic variations?
Thus implying that there *is* an abstract model lurking there?
Mind that when I say "XML is an encoding", I'm really stating that 'any
given bit of XML in fact encodes an instance of SOME data model', not
that there is a universal XML data model ;-) It all depends on the type
of XML.
But I suspect that there are few, if any, useful XML documents which
were written without some kind of intent in mind, and some (possibly
informal) model of what is significant and what isn't. For example, a
server-side script that serves XML over HTTP from a database query might
output:
<result>
<types name="String" email="EmailAddress" />
<row name="Alaric Snell" email="alaric@alaric-snell.com" />
...
</result>
While another might output it as:
<resultSet>
<header>
<col type="String">name</col>
<col type="URL(scheme='mailto')">email</col>
</header>
<rows>
<row index="1">
<field>Alaric Snell</field>
<field>mailto:alaric@alaric-snell.com</field>
</row>
...
</rows>
</resultSet>
...while yet others might output similar XML with more or less
indentation and blank lines and so on.
Yet all of these XML formats will just be representing this table of
names and email addresses. There is an underlying equivelance that a
human could grasp when presented with these two documents, but that
software would (currently!) need explaining to it (perhaps in the form
of XSLT converting either or both of the above formats to an expected
input format).
XML documents written as test cases or to demonstrate, I suppose, might
be said to have no intended information that they encode - and, indeed,
they are useless within actuall applications.
ABS
|
