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 ]

james.anderson@setf.de (james anderson) seems to be breathing
higher-grade oxygen that I am:
>> >markup is also cool for separating data and processes that act on
>> >that data. yes, it's pretty heavyweight and there's all kinds of
>> >more lightweight data interchange formats, but XML has got all this
>> >inertia behind it and really great toolsets. Otright disparaging
>> >the use of markup for purely machine communication can't be
>> >mainstream either. As long as you can pay someone (or get paid for)
>> >debugging a bunch of <UDWhatever_22> tags, then fine -- you get to
>> >use all the fancy APIs. Why is this bad? Purely maintenance, IMHO.
>> 
>> It's bad for a number of reasons.
>> 
>> First, lousy markup design - for that's what I'll call it - sets bad
>> precedents for people.  If all I've encountered is <UDWhatever_22>,
>
>if all you encountered was "<UDWhatever_22>", then you were not
>reading very carefully. the question was about dependancy, not
>exclusivity.

You had asked:
>why would one ever bother to encode or exchange any mention of
>ProductPartIdentifier, when the necessary and sufficient identifier is
>UDEF_9_5_8?

That seems to be exclusivity to me.  Perhaps you're using the term in
ways that go beyond my understanding of it.

>> and that's what I think XML is, I'm liable to run like hell rather
>> than deal with XML unless I'm paid an awful lot.  (That's my general
>> response to RDF/XML, and apparently it's not an unusual reaction.)
>> 
>> Second, that kind of markup is only useful until we can't find the
>> documentation any more.
>
>aren't the document definitions an integral component of the document?

Not according to XML 1.0.  They're quite plainly optional.

>>   For cases where the documentation is always
>> going to be absolutely positively necessary, maybe that's fine.
>
>where i to be confronted with the mountain of data in twenty years,
>i'd much rather find document entities full of <UDWhatever_22> and one
>document definition which mapped the canonical terms to some
>discursive definitions, than endless documents full of ideosyncratic
>generic identifiers and one document definition which mapped one
>vocabulary to the canonical terms.
>
>ymmv.

It varies every day.  I don't have twenty-year-old markup to deal with,
but I deal with lots of vocabularies regularly, many of which do similar
things slightly differently. (Heck, submitting the same paper to
different IDEAlliance conferences involves sorting those issues out.)
It's not that hard.

>> Third, you're accepting all the costs of markup - text processing,
>> verbose descriptions, etc. - and getting only a few of the benefits.
>
>is /@ that much more difficult than / ?

What language are you speaking?  If that's XPath, I didn't think we were
in the classic elements/attributes tussle.

>> Fourth, you're pretty much declaring that your markup is only to be
>> handled by trained professionals.
>
>how does that follow from reversing the dependancy?

It follows from:
>[not bothering] to encode or exchange any mention of
>ProductPartIdentifier, when the necessary and sufficient identifier is
>UDEF_9_5_8?

Thanks, but no thanks.

-- 
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org




 

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

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