[
Lists Home |
Date Index |
Thread Index
]
vdv@dyomedea.com (Eric van der Vlist) writes:
>Then the XML users are probably not the target audience of these
>applications!
Yeah, I've noticed. I frequently wish the RDF community would use N3
instead and drop the pretense, but that doesn't seem universally
plausible. Maybe they can develop an ASN.1 format...
>We are in the same situation with XML/RDF that we are with text/XML: I
>could choose to write a XML application which is "raw text friendly" by
>defining a specific serialisation and eventually publishing a regexp to
>validate my documents. By doing so I would give access to this
>application to programmers and tools both at the text and at the XML
>level but I would loose some of the flexibility of XML. If I don't do
>so, I forbid the access to raw text tools unless they are ready to cope
>with the complexity of XML.
As much as I value the text-ness of XML, making the regex approach work
smoothly would have demanded a different syntax, even before namespaces.
(Scoped xml: attributes and especially DOCTYPE effects are very
complicating. And XPath through pure regex? Maybe.) XML is text,
certainly, but it wasn't designed to be processable as raw text. I don't
think the comparison holds.
(Ripper combines a parser API and a context API. The parser part,
though it's had some glitches, is stable. The context part seems likely
to continue accumulating more tasks.)
>RDF applications have the same choice to do: either restrict their
>syntactical variations and loose some of their flexibility or forbid
>the access to XML tools unless these are ready to cope with the
>complexity of RDF syntax.
I see RDF colliding with XML, not particularly making choices that
indicate they have much/any interest in XML. RSS 1.0 is the only
significant exception that comes to mind, and it was competing in a
field where XML syntax processed by XML (and XMLish) tools was already
dominant.
>When they don't want to loose the flexibility of a full RDF layer
>access, they should just be honest enough to advert themselves as "pure
>RDF applications" and not take any XML label, just as most of the XML
>applications have rejected the label "raw text application".
I'd be happy to see RDF leave XML alone, sure. I agree that XML has for
the most part rejected "raw text application" - given its choices, I
think it had to.
>I don't see this as an issue we can fully fix, but as a price to pay
>when we pile specs on top of each other: each layer needs to have its
>own set of tools and mixing different layers requires some
>compromises...
As I've said before, I don't think RDF syntax makes many compromises,
except perhaps for the initial decision (mistake, IMHO) to use XML. It
got RDF some parsing toolkits, but that's about it. As David Megginson
notes, even Web document annotation hasn't really taken off.
>I think your reaction toward the RDF serialisation is very coherent
>with your quest of the perfect XML processing model which would keep
>all the properties of the text document behind the XML tags :-) !
Even if I was fond of the Infoset and only worked with SAX and DOM, I'd
find RDF's structural flexibility a gigantic irritant.
>Both are noble quests worth pursuing, but I don't think they can be
>fully met since they are kind of denying that structures in layers
>require a price to pay!
>
>Of course we should still try to minimise this price...
I think the price was set by the unfortunate coincidence that XML and
RDF were developed at the same institution. RDF's URI-ness infested XML
through namespaces, while XML trees have been a coarse fit for RDF
graphs.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
