Lists Home |
Date Index |
Great points. Your context references below (the USA address vs.
Germany address) are being covered by the work that is being done under
UN/CEFACT for Core Components . The context mechanisms that are
defined in the Core Components spec (which is still in approval phases)
are going to be applied in the Universal Business Language (UBL)
initiative  under OASIS, in their later releases. The new OASIS
Content Assembly Mechanism (CAM) TC  is actually very much focused on
this very thing - bringing together business process context and
localized implementation business rules to create XML documents.
Lastly, the OASIS/ebXML Registry TC  will be "core
component-enabling" the registry architecture in a future release. I am
heading up this effort, and we are on hold due to major changes in the
Core Components spec that took place last August (and are incorporated
in the latest release referenced in  below).
If this is in line with what you were thinking, I would recommend that
you track some or all of these efforts.
Booz | Allen | Hamilton
Owen Walcher wrote:
> >Now we have had five years of XML, we can see that there are
> >three main communities who are not well-served by the current
> >well-formed/valid distinction in XML: at the dumb end of town
> >are the SOAP people who don't need entities or a DOCTYPE declaration;
> >at the middle of town we have the XHTML people who do need
> >entities but don't need validation (or who will be switching to some
> >other XML schema language such as ISO DSDL instead of DTDs);
> >and at the grand end of town, the Schema and Query people wish
> >DTDs could go away faster.
> At the risk of being at the "dumb" end of the XML curve, I am looking to
> come up with a set of "codd-like" rules that lets me used well-formed XML in
> malleable/adaptive applications without the need for a DTD or Schema. Sure,
> XSLT lets me convert to whatever I like, assuming I know what is coming
> a-priori. But what if I don't know what is coming in, and I want to have a
> structure that helps me guess (like the implied context of a hierarchy)?
> I would like to be able to use these rules for both data and documents.
> This is why the attribute vs. element thing is what got me started.
> <sock pattern="Argyle"/> is the same as
> <sock><pattern>Argyle</pattern></sock> from an XML point of view,
> <sock pattern="Argyle">
> </sock> vs.
> Have two completely different semantics, in that the attribute
> pattern="Argyle" (in my opinion) should not be used because it does not
> further specify the size of the sock. Certainly <FONT color='red'/> can be
> interpreted as a presentation attribute, which might safely be ignored for
> non-presentation uses, but can <Address country="us" /> be so ignored (since
> this country attribute presumably helps the machine determine the follow-on
> structure as a USA address, vs. a Germany address, which would have
> completely different structure)?
> Many are using XML as a transport, and then shredding/CLOBing back into
> their rigid RDBMS structures (which is why XSD seems so desired by the
> "higher end XML gods"), but some of us are trying to push the art, and use
> things like Meta Object Protocols and Reflection to be able to handle TRULY
> heterogeneous and FULLY extensible XML documents.
> Is anyone else working along these lines to move programming from the
> cottage industry it now is into the current century?
> BTW: I am hoping this to be my doctoral dissertation subject, so please
> shred away!
> Owen "dumb, but wanting to be enlightened" Walcher
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
fn:Joseph M. Chiusano