Can be multiple instances of element used as the root element?

V

VK

Can be multiple instances of element used as the root element?

That's a curly way of asking, but I did not come up with a better
sentence, sorry. What I mean is with a document like:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<element>Content</element>
<root><element>Content</element></root>
<element>Content</element>
</root>

so <root> elements is used not only as a root element but inside the
document as well. Is this a valid (in the wide sense) markup?
 
M

Martin Honnen

VK wrote:

What I mean is with a document like:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<element>Content</element>
<root><element>Content</element></root>
<element>Content</element>
</root>

so <root> elements is used not only as a root element but inside the
document as well. Is this a valid (in the wide sense) markup?
Click to expand...

It is well-formed XML. Validity of markup can only be assessed if you
have a DTD or a schema against which to validate and your example does
not show any schema.
An example of what you have (e.g. the same element type as the root
element and as a possible child of the root element) is SVG 1.1 for
instance where the root element is an |svg| element in the namespace
http://www.w3.org/2000/svg and can contain further such |svg| elements.
 
P

Peter Flynn

VK said:
Can be multiple instances of element used as the root element?

That's a curly way of asking, but I did not come up with a better
sentence, sorry. What I mean is with a document like:

<?xml version="1.0" encoding="UTF-8"?>
<root>
<element>Content</element>
<root><element>Content</element></root>
<element>Content</element>
</root>
Click to expand...

Why not just run a parser on it and see?
so <root> elements is used not only as a root element but inside the
document as well.
Click to expand...

Yes, provided the document is well-formed this is OK, if unusual.
Is this a valid (in the wide sense) markup?
Click to expand...

Only if you have a Schema or DTD to provide validation criteria, eg:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ELEMENT root (element|root)+>
<!ELEMENT element (#PCDATA)>
]>
<root>
<element>Content</element>
<root><element>Content</element></root>
<element>Content</element>
</root>

However, except in specialist circumstances it's probably not good
design. Element type names are usually chosen to reflect some kind
of meaning, and it's hard to understand why you would want an
element type used both for the root element and for a descendant.

The closest analogy I can think of immediately is in the TEI, where
the second-level element <text> can be reused within a paragraph
(for example) when you are quoting an embedded document, like in a
story where someone reads or quotes a letter:

<TEI.2>
<teiHeader>
...etc...
</teiHeader>
<text>
<body>
<p>This is what he sent me:<text>
<body>
<salute>Dear Peter,</salute>
<p>...</p>
</body>
</text></p>
</body>
</text>
</tei.2>

That's not the root element, but I can't offhand think of anything
else doing this on a regular basis.

///Peter
 
V

VK

However, except in specialist circumstances it's probably not good
design. Element type names are usually chosen to reflect some kind
of meaning, and it's hard to understand why you would want an
element type used both for the root element and for a descendant.
Click to expand...

That is not about my XML markup - with all defaults I have I still
normally do not do things like that :)
As other respondent properly guessed that was about the current SVG1.1
DTD on W3C. I just made my question fully abstract to avoid an
"authority pressure".
I'm glad to see that at least one person is sharing my surprise
feelings. As I nowhere to be a XML specs guru, I wanted to compare my
natural (yet non-academical) reaction with someone else's.
 
J

Joseph Kesselman

Peter said:
However, except in specialist circumstances it's probably not good
design. Element type names are usually chosen to reflect some kind
of meaning, and it's hard to understand why you would want an
element type used both for the root element and for a descendant.
Click to expand...

Some data structures are conceptually recursive, which would yield
exactly this kind of structure. One obvious example is a departmental
tree, where a manager may manage other managers in addition to
non-management employees.
 
V

VK

Joseph said:
Some data structures are conceptually recursive, which would yield
> exactly this kind of structure. One obvious example is a departmental
tree, where a manager may manage other managers in addition to
non-management employees.
Click to expand...

IMHO a management tree is a strictly hierachical structure (as any
power chain in this matter). There is no "manager" as such unless as a
dictionary entry. There is store manager (one), assistant manager (each
time one on duty) and department managers (by the number of
departments).

<store_manager>
<assistant_manager>
<department_manager>
<working_bee>
</department_manager>
<department_manager>
<working_bee>
</department_manager>
</assistant_manager>
</store_manager>

that can be represented over attributes of course:

<manager type="store">
<manager type="assistant">
<manager type="department">
<working_bee>
</manager>
<manager type="department">
<working_bee>
</manager>
</manager>
</manager>

but it's lesser convenient (IMHO of course) as a data structure - and
still no recursion.

The question is than if SVG is conceptually recursive and
<svg>
<svg>
</svg>
</svg>
is the only way to solve it?
 
J

Joseph Kesselman

VK said:
IMHO a management tree is a strictly hierachical structure
Click to expand...

Depends on what you're doing with it. My point was just that recursive
data structures are not uncommon in programming, so we shouldn't be
surprised to see them used, and supported, in XML-based languages.
The question is than if SVG is conceptually recursive
Click to expand...

I haven't looked at the SVG formal spec, so I don't know. My uninformed
guess would be that that while the top-level <svg/> element itself may
not happen to recur, other data structures within that language probably do.
 
V

VK

Joseph said:
My point was just that recursive data structures are not uncommon
in programming, so we shouldn't be surprised to see them used,
and supported, in XML-based languages.
Click to expand...

Your point is taken.
I haven't looked at the SVG formal spec, so I don't know. My uninformed
guess would be that that while the top-level <svg/> element itself may
not happen to recur, other data structures within that language probably do.
Click to expand...

I may humbly ask everyone then to take a look at:
<http://www.w3.org/TR/SVG11/struct.html>
and
<http://www.w3.org/TR/SVG11/struct.html#SVGElement>

Poorly and briefly (at the best of my capabilities): each <svg>
(Scalable Vector Graphics) element defines an eternal geometrical
Decart space and a physically finit viewport ("window to the eternity")
to that space. In the currently proposed schema only the top level
<svg> may define the viewport, but any nested <svg> elements have their
viewports disregarded, they only have the right to map themselves to a
coords point in the Decart space of the outermost <svg>. This way I see
a XML structure where elements and their attributes are not treated by
DTD but by the node position in the tree.

Taking out the technical details, from purely structural positions:
would it be normal to give a special value to the node position of an
element in the tree (besides the element's rule in DTD). Or is it a
case of a recursive structure?
 
J

Joseph Kesselman

VK said:
Taking out the technical details, from purely structural positions:
would it be normal to give a special value to the node position of an
element in the tree (besides the element's rule in DTD). Or is it a
case of a recursive structure?
Click to expand...

"Normal" depends on the semantics of the XML-based language being
defined. For some applications it makes sense, for others it doesn't.

I'd call this one a case of recursive structure, defining the semantics
of embedding an SVG graphic within a larger SVG. Given the intent, it
makes perfect sense to me that the viewport is defined for the entire
image rather than for the contained fragment. But it's up to the
language's designers to make that decision.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

XHTML - how extend/create ELEMENT body in my DTD? 0
XSD: What is the root element 3
Two different element types with the same name ? 11
Root element specified by DTD ? 28
Undesired (maybe) attributes in root element of XSLT output 1
Why is only the root-element transformed? 0
Multiple Root Elements in Garmin POIs - is it legal XML? 10
XSD <any> element 0

Members online

Total: 500 (members: 2, guests: 498)
Robots: 451

Forum statistics

Threads
474,006
Messages
2,570,265
Members
46,861
Latest member
SanoraS48

Latest Threads

Top