[
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:
> > <!DOCTYPE SOME_UDEF SYSTEM "data:,<!ELEMENT UDEF_9_5_8 (#PCDATA) >" [
> > <!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"?
...
|
