[
Lists Home |
Date Index |
Thread Index
]
Then I ask you this question: can XML namespaces
be leveraged to help guide an author? I say it can.
<nikon:lens>
is better than
<lens>
At the very least, I don't have to use OR
groups to show the author what is expected.
BTW: I need schemas in my world. No D'oh.
There is a tension among several dimensions
of constraints that the markup designer has
to consider. Maybe we can identify these
and qualify them. To start:
1. What tools are available and what features
do they support? Without knowing this, everything
else is moot. It may be the case that no tools
are selected yet and that is part of the XML
expert's job. So much the better.
2. Does the end user do a part of the job or
all of the job of preparing the final bound
deliverable?
3. Is the order of assembly important? By
that, I mean the binding order of the document
into some fixed form for publishing.
4. Are some parts of the assembly/document
more important than others and why? Eg,
a paragraph description of a part assembly
vs the remove and replace procedure? Are
these verified/validated/edited independently?
(That can be the case in say, an LSAR driven
logistics environment)?
5. Is the document composed of different
XML vocabularies (eg, SVG, XHTML, etc.)?
6. Does size matter? Eg, size of the whole
entity, size of the tags, size of the data
content? Is this a medium-dependency (say
network messages) vs a tool dependency (say
editors for attributes)?
7. Should tag names be acronymized or
self-documenting? See 6 and 2.
I'm stopping there for the moment. Others?
Assertion (unproven): complexity of content
and complexity of markup are about the same if one
drops HTML or other forms of presentation
markup. One can always resort to generic
coding to eliminate complexity, but at that
point, markup itself becomes moot except
for cut and paste applications. One can
transform, but again, records of authority
aren't transformed unless proven reversible.
len
From: Jonathan Robie [mailto:jonathan.robie@datadirect-technologies.com]
It certainly interests me, especially if it involves real examples with
real schemas and usage scenarios and lots of pointy brackets.
I really like XML-Dev best when we're trying to work together to find
solutions to real technical problems. (I like to reminisce about the SAX
1.0 days ;-> )
|
