[
Lists Home |
Date Index |
Thread Index
]
- To: xml-dev@lists.xml.org
- Subject: Re: [xml-dev] reaching humans (was Re: [xml-dev] Extract A Subset of a W3C XML Schema?)
- From: "Simon St.Laurent" <simonstl@simonstl.com>
- Date: Fri, 1 Aug 2003 02:22:01 -0400
- In-reply-to: <3F29CF1B.795D26F8@setf.de>
james.anderson@setf.de (james anderson) writes:
>"Simon St.Laurent" wrote:
>> james.anderson@setf.de (james anderson) writes:
>> >despite the truism, that the generic identifer is just a special
>> >attribute, what is the advantage to making the universal depend on
>> >the ideosyncratic?
>>
>> That it's local.
>
>not everywhere.
I take it that you're saying localness is not an advantage everywhere.
In the context of the current thread, where universal appears to have
become conflated with abstract, I have to disagree.
Widely shared can be good, but given the choices you're proffering, I'll
take local and idiosyncratic any day.
>> I guess I just don't value the universal enough to participate in
>> your world.
>
>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.
>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. As far as reliability across programs and platforms is
concerned, HTML 1.0 is often more 'universal'. (I like CSS largely
because it works with whatever idiosyncratic markup I choose, when it
works.)
I think you must have a different meaning of as well as value for
universal.
>> 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.
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:
>> <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>
And claim "either you have got it right or you have not" - hardly a call
for the kind of flexibility AFs seem designed to provide.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|