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] reaching humans (was Re: [xml-dev] Extract A Subset of a

[ Lists Home | Date Index | Thread Index ]

"Simon St.Laurent" wrote:
> james.anderson@setf.de (james anderson) writes:
> ...
> >
> >but you would agree to the advantage of "<ol>" over ".TB 4", to go
> >back thirty years (http://www.sgmlsource.com/history/AnnexA.htm),
> The advantage there isn't in the universality - it's in the declarative
> approach over the procedural, as that annex makes clear.

it also does not suggest that one should encode <tb level="4" form="ol">

> >and admit the advantages of CSS over the HTML 1.0 rendering model? the
> >issuses are the same.
> The CSS model is no more or less 'universal' in scope than the HTML 1.0
> model.

wouldn't the interpretation model which binds the presentation properties to
the document components late, and infers them from a wide range of locational
and attributive criteria, rather than statically associating those properties
with the gi be the more universal of the two?

> ...
> >> I guess you're not fond of architectural forms either?
> >
> >i don't understand how anything i wrote would imply that.
> Well, on the one hand you seem to consider the DTD part of the
> document, which is good, given that AFs typically depend on fixed
> attributes.

as i recall, the objection, that the dtd is inherently optional, came from
someone else.

> On the other hand, you seem to want to use the primary
> identifier AS THE ELEMENT NAME, which seems counter to AF practice,
> where localization of element names is generally welcome.  To take the
> original example, you appear to dislike:

i made no general assertion. i am not asking here about how to process a
legacy document which i am postfacto annotating, and i am not asking about how
to deal with a document which i get from some fly-by-night in a back alley.
the question is about a document form recommended by a standards organization
which purports to codify terms which identify "what one is *really* talking about".

> >> <ProductPartIdentifier
> >>             UID="9_5.8">123-456-789</ProductPartIdentifier>
> In this case, the UID tells you what ProductPartIdentifer "really" is,
> and could be useful grist for an AF processor while still keeping the
> human-readable name around.
> You seem to prefer:
> >  <!ATTLIST UDEF_9_5_8 MIL-STD-2549 #FIXED "Part Product Identifier">
> > ]>
> > <UDEF_9_5_8>123-456-789</UDEF_9_5_8>
> >
> >or just
> >
> > <UDEF_9_5_8>123-456-789</UDEF_9_5_8>

in the particular context of my question, yes, i am surprised that the
document architecture would preclude an encoding directly in the primary
terms. i am surprised that the architecture would stipulate that each
recipient must reformulate the document from the sender's "local" terms. i am
also surprised that the document architecture would permit a situation where,
"twenty years from now", then legacy documents yield the then equivalent of a
404 when one tries to find out what the "local" terms mean.

hey, forget "twenty years from now". i am ever more amazed at how easy it is
to point my browser-of-choice at documents, in which, even though it happily
renders them completely perfectly correctly, i have no idea where the words
start and stop.

what was that term which popped up earlier for, among other things "disposed
to go counter to what is required"?



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

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