[topicmapmail] Fragmented XTM for web metadata, and some ontology?

[Kal Ahmed]

On Sun, 2003-06-29 at 13:39, Murray Altheim wrote:
> Kal Ahmed wrote:
> > On Sun, 2003-06-29 at 12:52, Murray Altheim wrote:
> [...]
> >>I've not attempted to provide a constraint language (as there are others
> >>spending far more time and effort than I'd ever on this problem), I'm
> >>concentrating on labeling/typing, which is a necessity in its own right.
> >>If if one can label a literal value with an XSD primitive, by extension
> >>there's no reason why one couldn't use the same approach to "label" it
> >>with a custom datatype, where the PSI points to a bit of XML Schema markup
> >>that actually provides that constraint, so *if* an application wished to,
> >>it could retrieve that markup and actually perform the constraint checking.
> > 
> > Yes, that is true and what you suggest would make a good way to solve
> > the problem of validating XML content from an XML namespace other than
> > the XTM 1.0 namespace. However, the issue for the XTM syntax is the
> > PCDATA content model of resourceData which prohibits XML content for the
> > element.
> 
> I understand that. But Kal, describe for me a reasonable approach to
> allowing arbitrary XML in <resourceData> that doesn't completely screw
> us in terms of interchange. Once you open that door, there's no closing
> it. I just don't see how that would make any sense given that the first
> document coming down the pike with unknown markup (or JavaScript code)
> is just completely opaque to an application that can't process it, or
> worse yet, transparent, i.e., the user doesn't even know what is missing.
> 

As I previously suggested, I don't see anything wrong with an
XTM-compliant parser doing no more than validating the resourceData
content as well-formed and making it available in the SAM as string
data. The validation of the resourceData content can be done at a higher
level. The XTM-compliant parser would be able to flag the string data as
well-formed XML and then at application level you would either handle
the XML or not.

> I argued this same case to the W3C HTML Working Group for years, where we
> had Dave Raggett and others advocating that we do away with having an HTML
> DTD at all and just defining things in terms of "tag sets". Had this come
> to pass, we'd never had an XHTML DTD at all, just some weird notion of a
> well-formed "XHTML" document where one could intermix anything anyone
> wanted anytime -- complete freedom, and completely useless to anyone
> except monopolists who import and export their own brand of proprietary
> markup muck (export "HTML" from MS Word to see what I mean). If you look
> at the latest XHTML 2.0 draft [1] you'll see they're still trying to
> figure out some way of specifying a language without using a schema.
> [okay, I should have wrapped this in <rant>. I just don't want us to go
> down that same road.]
> 

But I am not suggesting complete mix-n-match. I am suggesting one
particular place in the XTM DTD where XML from other namespaces would be
allowed. There is no question (in my mind) of changing the "XTM on top"
approach of the DTD that says that the topicMap element should be the
document element, nor is there any question of allowing other markup to
appear anywhere else than inside resourceData. I know that other people
have suggested such changes, but I leave it to them to defend that :)

Cheers,

Kal