[
Lists Home |
Date Index |
Thread Index
]
[> >> and > are james anderson. >> is Simon St.Laurent.]
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">
I never said it did, and I think you're continuing to conflate two
separate issues.
>> >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?
That seems to run quite thoroughly counter to your GI-only suggestions
elsewhere, and I'm not sure that it has anything to do with universality
per se in any case. I view CSS as a very convenient localization
mechanism.
>> >> 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.
No, it came from me.
I don't object to DTDs, just recognize that there are real costs to
relying on them to sort out what cryptic identifiers in the document
mean. If there have to be cryptic identifiers, I'd rather they live in
the DTD, as I feel that gives me better odds of sorting out the
document's meaning when the DTD isn't available.
>> 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".
I'm hardly limited to back alleys or legacy documents. Standards
organizations or no, I'd much prefer to work with XML on terms which are
human-friendly. If I didn't care about that, ASN.1 and other specs are
just as good or better at representing "what one is *really* talking
about".
Architectural forms let me work with data on terms I find useful while
still preserving the possibility of working with other systems that have
their own preferences - by letting us get to "what one is *really*
talking about" through a minor transformation. It seems to me like a
good way to encourage developers and users to work in the context of
standards documents without forcing the kinds of groans that
<UDEF_9_5_8> is likely to produce.
>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 don't think anyone's precluded that possibility. If you'd like to
work in <UDEF_9_5_8>, you can. Just don't expect anyone else to enjoy
it or consider it "required".
>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.
Relative to sorting out what <UDEF_9_5_8> means, I don't see that as
much of a problem. I also expect meanings to drift over time, and
people twenty years from now to be looking for different things in the
data, so I don't think I have much sympathy here.
>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.
Whitespace oddities in IE's XSLT handling aside, where are you losing
word separations? And can you find them in the original unmediated
markup?
>what was that term which popped up earlier for, among other things
>"disposed to go counter to what is required"?
Dunno. I think I lost track when you were complaining about the
slowness of pencil sharpeners. :)
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
