OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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

Message text written by John McClure
>For <Purchaser.FirstName>, the Interpreter learns from the DCD that
'FirstName' is a subclass of "Memo" and "Entry", and is valid for resources
of type 'Person'. It also learns that 'Purchaser' is a subclass of
'ActorRole' and 'Role'. Put these facts together, and the appropriate DOM
tree can now be generated with little problem.

There are enough other pieces to this that it is appropriate to call this
kind of markup a DCN-specific <!NOTATION>, a subtype of the XML notation
embedded in parsers today. In part because the notation generates a DOM
that is DCN-specific, using elements from a DTD that is expected to change
very little over time. And in part because there is no difference (the same
DOM fragment is generated) between


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.

You further stated >>>

I must admit to remaining puzzled over why UIDs seem so attractive
in the face of URIs and XML Namespaces. 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.

Here's the rub - your wonderful example above top is a classic example :

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.

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.

Just practical implementation in a business context.

Thanks, DW.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC