Regarding terminology of fragid-best-practices

Dear TAG,

I have problems understanding http://www.w3.org/TR/fragid-best-practices 
mainly due to the bulky terminology used.

1. http://tools.ietf.org/html/rfc2046 clearly defines the terms "media 
type, subtype, and zero or more optional parameters" . In the current 
draft it is often unclear, if you refer to type or subtype. "subtype" is 
not mentioned once.

2. The current working draft talks a lot about  "named structured syntax 
suffix". There is only the IETF draft who uses this expression to 
explain the registration procedure. It would simplify the working draft, 
if you would make the name more intuitive such as in "subtype syntax", 
especially since "syntax" implies "structured" and "suffix" or 
"registered" implies "named".  The actual "+suffix" is of minor 
importance here in comparison to the IETF draft, so for me it would make 
more sense to talk about "subtype syntax definition", rather than the 
"named structured syntax suffix registration".

3. Throughout the document you use fragment identifier "rules", 
"processing requirements", "constraints", "processing behaviour".  I 
believe, what you really want to say is, that: "A fragment identifier 
structure is a defined set of fragment identifier syntax, semantics and 
pragmatics", the classical trinity of "form", "meaning" and "use".  The 
level of "meaning" specifies, what the fragment identifier "refers to", 
"selects" or "denotes" ; the level of "use" defines constraints, 
behaviour, rules, etc.

Please see the change:
"Media type registrations should avoid "inheriting" generic fragment 
identifier rules from both the top-level type and any structured syntax 
suffix that they use if the fragment identifier syntaxes defined for 
these overlap and may provide different meanings for the same fragment 
identifier. "
would be:
"Media *sub*type registrations should avoid "inheriting" fragment 
identifier semantics and pragmatics from type, subtypes and any subtype 
syntax definitions that they use if the fragment identifier syntaxes 
defined for these overlap and may provide inconsistent meanings or 
conflicting usage for the same fragment identifier."

"Structured syntax suffix registrations should define processor 
behaviour for fragment identifiers that is consistent with the relevant 
associated generic media type."
would become:
"Subtype syntax definitions should define fragment identifier pragmatics 
that are consistent with the associated media type." (associated and 
generic are superfluous)"
Note, before it was unclear, whether "behaviour" includes "semantics". 
E.g. it does not make sense to make an XPointer fragment identifier 
refer to a fragment of an image.

4. Best Practices 1-2-3-6-7-8 are mostly the same, i.e. saying that 
syntax, semantics and pragmatics should be  consistent for subtypes 
regarding subtype syntax and type, i.e. no ambiguity, no uncertainty. 
Equal syntax should imply equivalent meaning.
( I must admit, that I was unable to cognitively wrap my head around 7, 
at all)

5. Section 6: The definitions for "syntax-based" and "semantic" fragment 
identifier structures are very fuzzy and I am unable to understand them.
Which category does "plain name fragment identifier" fall into? Why is 
xPointer syntax-based? I would assume that addressing parts of the DOM 
is definitely "application-level understanding of its meaning" . What is 
the main criteria distinguishing both categories? It sounds like the 
syntax-based is for the subtype syntax and the semantic is for the media 
type? Maybe you can categorize them by what level they specify. And what 
about subtypes that do not have a subtype syntax definition, e.g. 
text/html ?

I hope, what I wrote is not complete nonsense. I am currently trying to 
see what is what for myself.
All the best,
Sebastian

-- 
Dipl. Inf. Sebastian Hellmann
Department of Computer Science, University of Leipzig
Events:
   * http://sabre2012.infai.org/mlode (Leipzig, Sept. 23-24-25, 2012)
   * http://wole2012.eurecom.fr (*Deadline: July 31st 2012*)
Projects: http://nlp2rdf.org , http://dbpedia.org
Homepage: http://bis.informatik.uni-leipzig.de/SebastianHellmann
Research Group: http://aksw.org

Received on Friday, 3 August 2012 01:29:59 UTC