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

[John McClure <hypergrove@olympus.net>]

David says:
> This is interesting - and I personally would like to explore this in the
> context of TREX - where I see some interesting overlaps and potential to
> build on an emerging simplified schema system that would directly
> support alot of this.

Wow. I'm an old REXX guy, and that language has dotted-names too. Doesn't
Python also use dotted-names? I guess it goes to show that it's hard to be
original, but perhaps not as hard as we may think to integrate best
practices learned over the years of s/w development. It's a mystery to me
why dotted-names aren't more commonly used, when XML has the capacity for it
just fine. I did see dotted-names in the Electronic Business Card (vCard)
spec, for attribute names, now that I think about it.

>> For <Purchaser.FirstName>, the Interpreter learns from the DCD that
>> 'FirstName' is a subclass of "Memo" and "Entry",
>
> Now - the problem is - what if my interpreter does not 'learn' quite the
> way your does?  The human is certainly not going to be able to
> unravel all the hidden nuances of all this layer on layer on layer
> abstraction with RDF, URI's and Namespaces.  Whereas the
> simple and direct UID provides a goof-proof associative mechanism
> that can be manually cross-checked and verified and implemented.

I don't understand what your interpreter is learning if it is using the same
dictionary that is referenced by the instance document. The UID is just a
string, like a URI, to which you propose be assigned the same semantic
purpose as a URI. Frankly, I find 'EBXML1234567' the antithesis of
goof-proof, and would rather use a descriptive name or a URI. The DCN uses
the 'name' attribute and RDF uses the <rdf:type> element/attribute whose
value is a URI. I doubt I'll be convinced otherwise.

>
> Too many of us have been in the trenches of data transactions and
> prefer something direct and simple.  Once we have that all working
> then we can build from there to reach for the potential wonder of
> what you are engineering.

Hmm, you imply that dotted-tagnames aren't practical. Isn't this exactly
what ebXML has in mind -- to use a dictionary of cross-associated data
models as a guide to semantic parsing, to generation of DTDs, to
translations between languages? Perhaps the DCN, by virtue of its taxonomy,
is today semantically more muscular than the Core Components spreadsheet
dictionary, but that may change as the ebXML architecture is evaluated on
its merits by the development community. I believe that my proposed
'flattening' of the structure of the elements in an instance document is
feasible, but then again you may know more about this than I do!

Regards,
John McClure
Hypergrove Engineering
211 Taylor Street, Suite 32-A
Port Townsend, WA 98368
360-379-3838 (land)