Re: Namespaces and ixml

Presumably, this email is to lay the ground work for justifying why @ and ^ marks are reasonable inclusions in iXML, but namespaces aren't.
> XML is one of the targets for that explicit output, and currently the best
> for representing the abstractions. It need not be the only one
I can agree with this, and I wish we hadn't wasted so much time so that we could have explored other output formats, and what they would mean.

Unfortunately, there's a lot in this email which I find unsatisfactory.
> input -> ixml -> output
>
> The real ixml is that middle bit.

That's news to me; it's certainly not what you've put in the spec:
> Invisible XML (ixml) is a method for treating non-XML documents as if they were XML, enabling authors to write documents and data in a format they prefer while providing XML for processes that are more effective with XML content.
I struggle to identify what that middle bit is, in 'real' terms: the best I can do is interpret it as the parse tree, which the spec doesn't attempt to proscribe for implementations.  Or else the process itself, including any grammar.  It seems too low resolution to impart useful meaning.
> @ represents data that is made unstructured on output (you could say it
> is destructured).
Again, this is not what is in the spec, where it talks exclusively, explicitly about attributes.

For XML outputs, attributes are unstructured, but so are text nodes.  For non XML attributes such as JSON, what is the meaning of an unstructured output?  I suggest that this only has meaning because of the nature of the output format you are using.

And I think therein lies the problem; that if you want to turn implicit structure explicit, then the extra information to do so needs to be held in the grammar, and what that extra explicit information needs to be will depend on what the output format is.  It is not a weakness that iXML requires either the input or the output to be XML, it is what makes it rich enough to be useful.

Regardless of the original inspiration, what we have been actually working on for over a year now is specifically about a particular output format.  I think the nest has already been lined (rather than fouled), and probably has been since iXML was named.  Trying at this point to reposition the spec as being output format agnostic would be the more self-damaging approach.

Tom

_________________
Tomos Hillman
eXpertML Ltd
+44 7793 242058
On 2 May 2022, 23:32 +0100, Steven Pemberton <steven.pemberton@cwi.nl>, wrote:
> ixml is about taking implicitly structured (textual) data, recognising that
> implicit structure, and making it explicit in some way or another on
> output.
>
> XML is one of the targets for that explicit output, and currently the best
> for representing the abstractions. It need not be the only one, even though
> I recognise that some of you are involved only because of the XML aspect.
>
> input -> ixml -> output
>
> The real ixml is that middle bit.
>
> However, ixml is not XML, nor, contrary to what you may think, does it
> contain any XML-specific items:
> ^ represents structured data, and was initially chosen because it looks
> like a tree, and has the added benefit of looking like an XML bracket on
> its side.
> @ represents data that is made unstructured on output (you could say it
> is destructured). I had several candidates for the mark, such as =, which
> looks flattened and un-tree-like, but in the end I chose @ as the symbol
> used in XML for flat data.
>
> Namespaces are not a concept anywhere within ixml, nor do they map to any
> concept within ixml. It is purely a feature of XML, and one that was not
> even originally in the design of ixml ("not for generating any particular
> version of XML"). Adding explicit notation for namespaces somewhat fouls
> the ixml nest, making it specifically about a particular output format.
>
> I proposed a way of doing namespaces using the existing mechanisms:
>
> data: @xmlns:iso, iso:date+.
> @xmlns:iso: ^"http://example.com/ns/date".
> iso:date: ...etc...
>
> My feeling is that even if there were another notation added as well for
> namespaces, the method above would have to work anyway.
> So why would we want to have two methods of doing the same thing?
>
> The call tomorrow is immediately before me giving the talk of my life to an
> audience of 4000 people, so I'm hoping it won't become too quarrelsome.
>
> Speak to you tomorrow.
>
> Best wishes from New Orleans,
>
> Steven
>