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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] A question of necessity

On Fri, 22 Apr 2016 18:13:09 +1000, Alexander Johannesen
<alexander.johannesen@gmail.com> wrote:

| Arjun Ray <arjun.ray@verizon.net> wrote: 
| > In what ways would treating colonified names as atomic names have
| > made things difficult for you?
| What's an atomic name in XML? Do you mean, treat it as any other
| element with no special treatment?

An atomic string, like a name in SGML.  Something that doesn't have
internal structure as far as XML parsing is concerned (i.e. not part
of the definition of XML).

| I use a lot of XSLT where the namespace schema declaration is what 
| changes depending on context [...] For example;
|    <nut:template xmlns:nut="http://schema.shelter.nu/nut/v1";> ...
| </nut:template>
| vs.
|    <nut:template xmlns:nut="http://schema.shelter.nu/nut/v2";> ...
| </nut:template>

I don't claim to understand this, but I see a prima facie example of
"neurosis", as per a celebrated post to this list a while back:


| But again, necessary? In the way the system is designed, yes. But it
| can be designed differently, as always. So I'm still wondering what
| necessary mean. :)

Were colonified names necessary to implement the desired application
semantics (i.e. how a sample instance would be processed)?  Let's say
you had only non-XML-namespace aware tools available.  Would the
information representation problem have been difficult?  Impossible? 
| > Please define, or at least clarify, mixed content models and sanity
| > thereof.
| <nut:upper name="object">
|    <smic:middle name="passive">
|       <core:object>
|          ... properties ...
|       </core:object>
|    </smic:middle>
|    <smic:middle name="active" /> <!-- parsed as original -->
| </nut:upper>
| I "speak" the NUT and SMIC ontologies fluently, so when I create the
| core ontology (core namespace), I wrap them up like this.

I don't claim to understand this either (and I haven't the first clue
about either NUT or SMIC, what they are or what they could be for), so
I'll simply guess that by "mixed content model" you mean an element
structure hierarchy exhibiting generic indentifiers from more than one
"namespace" (thus, we have a <nut:upper> "containing" a <smic:middle>
"containing" a <core:object>, and so on.)  But I won't even try to
guess the difference between sanity and insanity. 

| For each domain there's a generic stylesheet for parsing, and one for
| version rules.

I need a stylesheet to parse?

| Again, can I do it with plain names? Sure, but very, very differently.

Okay.  Colonified names were not necessary.
| > That is, the necessity of "universal names" was simply laid down by
| > fiat.  I still don't think that was good enough.
| Hang on. Are you opposing namespaces, or the ruleset implementation of
| namespaces in XML? 

I'm not sure what you mean by "ruleset implementation".  The XML
Namespaces spec purports to define a syntactic mechanism to "uniquify"
names lest they "clash" or "collide".  So the implementation consists
of a definition of non-atomic names, i.e. with internal structure.  

Never mind that the "collision problem" is a fallacy, albeit a
deep-seated one.


My general take on the namespace concept, as it could apply to XML, is
that it's a matter of annotation, not of syntax.

| There's rules in it I certainly don't agree with, but the overall idea
| certainly fits me well. 

Note that the common-sense notion of a namespace as a controlled set
of names doesn't apply.  (The phrase made an appearance in some of the
trial balloons, I mean drafts, but it quickly vanished.)

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS