RE: Dotted-name Tags (was RE: Long Tags Codes etc. again)

[John McClure <hypergrove@olympus.net>]

William,
No, every data is not a CDATA or NMTOKEN, but then again, my hope is that
these are not being eliminated. For instance, I really do want to be able to
say that the date of an event is Thursday, not '2001-04-19' -- surely that
requirement will still be accommodated. Raising data-types as an issue seems
a distraction though, because an element has BOTH what I call 'presentation'
text and a string containing a value that has been 'formatted' (usu. per the
W3C spec).

For instance, the DCN's <instant> element (derived from the XML Schema
datatype), handles this by defining the 'value' attribute as holding the
ISO-formatted date/time value.

<instant value='2001-04-19'> this Thursday </instant>

But this begs your real question maybe, about this 'RDF world'. Sure, I
spoke dramatically, neglecting to note that there is a place for XML Schemas
(and DTDs!) however NOT as the primary method for representing a dictionary.
I wrote a paper two years ago (posted at LegalXML) comparing these
technologies, and concluded then that RDF Schema is clearly the superior
vehicle for expressing object class definitions. In other words, the 'RDF
world' is one where the greatest majority of metadata is stored in a
dictionary, one expressed using RDF Schema as its primary container yet
decorated with elements from many other namespaces, e.g., DAML, RuleML, and
even ebXML elements! The note suggested otherwise, that a UID -- an
identifier of a semantic element -- would be in the XSD or the DTD.

Beyond dictionaries, XML Schema does have its roles. Since DTDs and XML
Schemas can be generated from the DCD, then documents can still be
validated, and schema-driven data entry can still happen. These generated
schemas and DTDs certainly will reference the XML Schema datatype
structures, since that is how XML Schema-driven processors (will) work, and
that class of software certainly needs to be accommodated by the standard.

Second, the DCN's DTD/XSD can validate the in-memory DOM tree created by the
Interpreter. I have mentioned before that the DCN will have an XSD
reflecting the abstract/concrete relationship between the 15 resource-types
and the categories defined in the DCD for those resource-types, i.e., note
that the xsi:type attribute -- used alot -- is defined by the XML Schema
Instance (XSI) namespace.

And I should mention that XML Schema datatypes are represented as classes in
RDF Schema... so the loop is closed.

> -----Original Message-----
> From: William J. Kammerer [mailto:wkammerer@foresightcorp.com]
> Sent: Tuesday, April 17, 2001 7:17 PM
> To: 'ebXML Core' (E-mail)
> Subject: Re: Dotted-name Tags (was RE: Long Tags Codes etc. again)
>
>
> John "DD" McClure says "Mark Crawford's beliefs seem rooted in an XML
> Schema and DTD world, one that I hope fervently is left behind by the
> RDF Schema world coming upon us."
>
> I can kind of see how structure is enforced by RDF Schema - but how
> would we enforce data typing without an XML schema? - are we back to the
> bad old days of DTDs where every piece of terminal data is a CDATA or
> NMTOKEN?
>
> Of course, this is a "mere" implementation question, because we can
> actually implement ebXML Core Components any number of ways once we have
> a rich set of them devised - and discovery techniques in place for
> churning out more.
>
> Unfortunately, after 18 months of lip-flapping, the ebXML catalog seems
> woefully scrawny.  It would have been nice to have a number of core
> components that we could throw at John for modeling in his architecture.
> That would be one way he could convince us of the merits of DCN and RDF.
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
>
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>